1ovs-fields(7) Open vSwitch Manual ovs-fields(7)
2
6 ovs-fields - protocol header fields in OpenFlow and Open vSwitch
7
9 This document aims to comprehensively document all of the fields, both
10 standard and non-standard, supported by OpenFlow or Open vSwitch,
11 regardless of origin.
12 Fields
14 A field is a property of a packet. Most familiarly, data fields are
15 fields that can be extracted from a packet. Most data fields are copied
16 directly from protocol headers, e.g. at layer 2, the Ethernet source
17 and destination addresses, or the VLAN ID; at layer 3, the IPv4 or IPv6
18 source and destination; and at layer 4, the TCP or UDP ports. Other
19 data fields are computed, e.g. ip_frag describes whether a packet is a
20 fragment but it is not copied directly from the IP header.
21 Data fields that are always present as a consequence of the basic net‐
23 working technology in use are called called root fields. Open vSwitch
24 2.7 and earlier considered Ethernet fields to be root fields, and this
25 remains the default mode of operation for Open vSwitch bridges. When a
26 packet is received from a non-Ethernet interfaces, such as a layer-3
27 LISP tunnel, Open vSwitch 2.7 and earlier force-fit the packet to this
28 Ethernet-centric point of view by pretending that an Ethernet header is
29 present whose Ethernet type that indicates the packet’s actual type
30 (and whose source and destination addresses are all-zero).
31 Open vSwitch 2.8 and later implement the ``packet type-aware pipeline’’
33 concept introduced in OpenFlow 1.5. Such a pipeline does not have any
34 root fields. Instead, a new metadata field, packet_type, indicates the
35 basic type of the packet, which can be Ethernet, IPv4, IPv6, or another
36 type. For backward compatibility, by default Open vSwitch 2.8 imitates
37 the behavior of Open vSwitch 2.7 and earlier. Later versions of Open
38 vSwitch may change the default, and in the meantime controllers can
39 turn off this legacy behavior, on a port-by-port basis, by setting
40 options:packet_type to ptap in the Interface table. This is significant
41 only for ports that can handle non-Ethernet packets, which is currently
42 just LISP, VXLAN-GPE, and GRE tunnel ports. See ovs-vwitchd.conf.db(5)
43 for more information.
44 Non-root data fields are not always present. A packet contains ARP
46 fields, for example, only when its packet type is ARP or when it is an
47 Ethernet packet whose Ethernet header indicates the Ethertype for ARP,
48 0x0806. In this documentation, we say that a field is applicable when
49 it is present in a packet, and inapplicable when it is not. (These are
50 not standard terms.) We refer to the conditions that determine whether
51 a field is applicable as prerequisites. Some VLAN-related fields are a
52 special case: these fields are always applicable for Ethernet packets,
53 but have a designated value or bit that indicates whether a VLAN header
54 is present, with the remaining values or bits indicating the VLAN
55 header’s content (if it is present).
56 An inapplicable field does not have a value, not even a nominal
58 ``value’’ such as all-zero-bits. In many circumstances, OpenFlow and
59 Open vSwitch allow references only to applicable fields. For example,
60 one may match (see Matching, below) a given field only if the match
61 includes the field’s prerequisite, e.g. matching an ARP field is only
62 allowed if one also matches on Ethertype 0x0806 or the packet_type for
63 ARP in a packet type-aware bridge.
64 Sometimes a packet may contain multiple instances of a header. For
66 example, a packet may contain multiple VLAN or MPLS headers, and tun‐
67 nels can cause any data field to recur. OpenFlow and Open vSwitch do
68 not address these cases uniformly. For VLAN and MPLS headers, only the
69 outermost header is accessible, so that inner headers may be accessed
70 only by ``popping’’ (removing) the outer header. (Open vSwitch supports
71 only a single VLAN header in any case.) For tunnels, e.g. GRE or VXLAN,
72 the outer header and inner headers are treated as different data
73 fields.
74 Many network protocols are built in layers as a stack of concatenated
76 headers. Each header typically contains a ``next type’’ field that
77 indicates the type of the protocol header that follows, e.g. Ethernet
78 contains an Ethertype and IPv4 contains a IP protocol type. The excep‐
79 tional cases, where protocols are layered but an outer layer does not
80 indicate the protocol type for the inner layer, or gives only an
81 ambiguous indication, are troublesome. An MPLS header, for example,
82 only indicates whether another MPLS header or some other protocol fol‐
83 lows, and in the latter case the inner protocol must be known from the
84 context. In these exceptional cases, OpenFlow and Open vSwitch cannot
85 provide insight into the inner protocol data fields without additional
86 context, and thus they treat all later data fields as inapplicable
87 until an OpenFlow action explicitly specifies what protocol follows. In
88 the case of MPLS, the OpenFlow ``pop MPLS’’ action that removes the
89 last MPLS header from a packet provides this context, as the Ethertype
90 of the payload. See Layer 2.5: MPLS for more information.
91 OpenFlow and Open vSwitch support some fields other than data fields.
93 Metadata fields relate to the origin or treatment of a packet, but they
94 are not extracted from the packet data itself. One example is the phys‐
95 ical port on which a packet arrived at the switch. Register fields act
96 like variables: they give an OpenFlow switch space for temporary stor‐
97 age while processing a packet. Existing metadata and register fields
98 have no prerequisites.
99 A field’s value consists of an integral number of bytes. For data
101 fields, sometimes those bytes are taken directly from the packet. Other
102 data fields are copied from a packet with padding (usually with zeros
103 and in the most significant positions). The remaining data fields are
104 transformed in other ways as they are copied from the packets, to make
105 them more useful for matching.
106 Matching
108 The most important use of fields in OpenFlow is matching, to determine
109 whether particular field values agree with a set of constraints called
110 a match. A match consists of zero or more constraints on individual
111 fields, all of which must be met to satisfy the match. (A match that
112 contains no constraints is always satisfied.) OpenFlow and Open vSwitch
113 support a number of forms of matching on individual fields:
114 Exact match, e.g. nw_src=10.1.2.3
116 Only a particular value of the field is matched; for
117 example, only one particular source IP address. Exact
118 matches are written as field=value. The forms accepted
119 for value depend on the field.
120 All fields support exact matches.
122 Bitwise match, e.g. nw_src=10.1.0.0/255.255.0.0
124 Specific bits in the field must have specified values;
125 for example, only source IP addresses in a particular
126 subnet. Bitwise matches are written as field=value/mask,
127 where value and mask take one of the forms accepted for
128 an exact match on field. Some fields accept other forms
129 for bitwise matches; for example,
130 nw_src=10.1.0.0/255.255.0.0 may also be written
131 nw_src=10.1.0.0/16.
132 Most OpenFlow switches do not allow every bitwise match‐
134 ing on every field (and before OpenFlow 1.2, the protocol
135 did not even provide for the possibility for most
136 fields). Even switches that do allow bitwise matching on
137 a given field may restrict the masks that are allowed,
138 e.g. by allowing matches only on contiguous sets of bits
139 starting from the most significant bit, that is, ``CIDR’’
140 masks [RFC 4632]. Open vSwitch does not allows bitwise
141 matching on every field, but it allows arbitrary bitwise
142 masks on any field that does support bitwise matching.
143 (Older versions had some restrictions, as documented in
144 the descriptions of individual fields.)
145 Wildcard, e.g. ``any nw_src’’
147 The value of the field is not constrained. Wildcarded
148 fields may be written as field=*, although it is unusual
149 to mention them at all. (When specifying a wildcard
150 explicitly in a command invocation, be sure to using
151 quoting to protect against shell expansion.)
152 There is a tiny difference between wildcarding a field
154 and not specifying any match on a field: wildcarding a
155 field requires satisfying the field’s prerequisites.
156 Some types of matches on individual fields cannot be expressed directly
158 with OpenFlow and Open vSwitch. These can be expressed indirectly:
159 Set match, e.g. ``tcp_dst ∈ {80, 443, 8080}’’
161 The value of a field is one of a specified set of values;
162 for example, the TCP destination port is 80, 443, or
163 8080.
164 For matches used in flows (see Flows, below), multiple
166 flows can simulate set matches.
167 Range match, e.g. ``1000 ≤ tcp_dst ≤ 1999’’
169 The value of the field must lie within a numerical range,
170 for example, TCP destination ports between 1000 and 1999.
171 Range matches can be expressed as a collection of bitwise
173 matches. For example, suppose that the goal is to match
174 TCP source ports 1000 to 1999, inclusive. The binary rep‐
175 resentations of 1000 and 1999 are:
176 01111101000
178 11111001111
179 The following series of bitwise matches will match 1000
182 and 1999 and all the values in between:
183 01111101xxx
185 0111111xxxx
186 10xxxxxxxxx
187 110xxxxxxxx
188 1110xxxxxxx
189 11110xxxxxx
190 1111100xxxx
191 which can be written as the following matches:
194 tcp,tp_src=0x03e8/0xfff8
196 tcp,tp_src=0x03f0/0xfff0
197 tcp,tp_src=0x0400/0xfe00
198 tcp,tp_src=0x0600/0xff00
199 tcp,tp_src=0x0700/0xff80
200 tcp,tp_src=0x0780/0xffc0
201 tcp,tp_src=0x07c0/0xfff0
202 Inequality match, e.g. ``tcp_dst ≠ 80’’
205 The value of the field differs from a specified value,
206 for example, all TCP destination ports except 80.
207 An inequality match on an n-bit field can be expressed as
209 a disjunction of n 1-bit matches. For example, the
210 inequality match ``vlan_pcp ≠ 5’’ can be expressed as
211 ``vlan_pcp = 0/4 or vlan_pcp = 2/2 or vlan_pcp = 0/1.’’
212 For matches used in flows (see Flows, below), sometimes
213 one can more compactly express inequality as a higher-
214 priority flow that matches the exceptional case paired
215 with a lower-priority flow that matches the general case.
216 Alternatively, an inequality match may be converted to a
218 pair of range matches, e.g. tcp_src ≠ 80 may be expressed
219 as ``0 ≤ tcp_src < 80 or 80 < tcp_src ≤ 65535’’, and then
220 each range match may in turn be converted to a bitwise
221 match.
222 Conjunctive match, e.g. ``tcp_src ∈ {80, 443, 8080} and tcp_dst
224 ∈ {80, 443, 8080}’’
225 As an OpenFlow extension, Open vSwitch supports matching
226 on conditions on conjunctions of the previously mentioned
227 forms of matching. See the documentation for conj_id for
228 more information.
229 All of these supported forms of matching are special cases of bitwise
231 matching. In some cases this influences the design of field values.
232 ip_frag is the most prominent example: it is designed to make all of
233 the practically useful checks for IP fragmentation possible as a single
234 bitwise match.
235 Shorthands
237 Some matches are very commonly used, so Open vSwitch accepts shorthand
239 notations. In some cases, Open vSwitch also uses shorthand notations
240 when it displays matches. The following shorthands are defined, with
241 their long forms shown on the right side:
242 eth packet_type=(0,0) (Open vSwitch 2.8 and later)
244 ip eth_type=0x0800
246 ipv6 eth_type=0x86dd
248 icmp eth_type=0x0800,ip_proto=1
250 icmp6 eth_type=0x86dd,ip_proto=58
252 tcp eth_type=0x0800,ip_proto=6
254 tcp6 eth_type=0x86dd,ip_proto=6
256 udp eth_type=0x0800,ip_proto=17
258 udp6 eth_type=0x86dd,ip_proto=17
260 sctp eth_type=0x0800,ip_proto=132
262 sctp6 eth_type=0x86dd,ip_proto=132
264 arp eth_type=0x0806
266 rarp eth_type=0x8035
268 mpls eth_type=0x8847
270 mplsm eth_type=0x8848
272 Evolution of OpenFlow Fields
274 The discussion so far applies to all OpenFlow and Open vSwitch ver‐
275 sions. This section starts to draw in specific information by explain‐
276 ing, in broad terms, the treatment of fields and matches in each Open‐
277 Flow version.
278 OpenFlow 1.0
280 OpenFlow 1.0 defined the OpenFlow protocol format of a match as a
282 fixed-length data structure that could match on the following fields:
283 · Ingress port.
285 · Ethernet source and destination MAC.
287 · Ethertype (with a special value to match frames that lack
289 an Ethertype).
290 · VLAN ID and priority.
292 · IPv4 source, destination, protocol, and DSCP.
294 · TCP source and destination port.
296 · UDP source and destination port.
298 · ICMPv4 type and code.
300 · ARP IPv4 addresses (SPA and TPA) and opcode.
302 Each supported field corresponded to some member of the data structure.
304 Some members represented multiple fields, in the case of the TCP, UDP,
305 ICMPv4, and ARP fields whose presence is mutually exclusive. This also
306 meant that some members were poor fits for their fields: only the low 8
307 bits of the 16-bit ARP opcode could be represented, and the ICMPv4 type
308 and code were padded with 8 bits of zeros to fit in the 16-bit members
309 primarily meant for TCP and UDP ports. An additional bitmap member
310 indicated, for each member, whether its field should be an ``exact’’ or
311 ``wildcarded’’ match (see Matching), with additional support for CIDR
312 prefix matching on the IPv4 source and destination fields.
313 Simplicity was recognized early on as the main virtue of this approach.
315 Obviously, any fixed-length data structure cannot support matching new
316 protocols that do not fit. There was no room, for example, for matching
317 IPv6 fields, which was not a priority at the time. Lack of room to sup‐
318 port matching the Ethernet addresses inside ARP packets actually caused
319 more of a design problem later, leading to an Open vSwitch extension
320 action specialized for dropping ``spoofed’’ ARP packets in which the
321 frame and ARP Ethernet source addressed differed. (This extension was
322 never standardized. Open vSwitch dropped support for it a few releases
323 after it added support for full ARP matching.)
324 The design of the OpenFlow fixed-length matches also illustrates com‐
326 promises, in both directions, between the strengths and weaknesses of
327 software and hardware that have always influenced the design of Open‐
328 Flow. Support for matching ARP fields that do fit in the data structure
329 was only added late in the design process (and remained optional in
330 OpenFlow 1.0), for example, because common switch ASICs did not support
331 matching these fields.
332 The compromises in favor of software occurred for more complicated rea‐
334 sons. The OpenFlow designers did not know how to implement matching in
335 software that was fast, dynamic, and general. (A way was later found
336 [Srinivasan].) Thus, the designers sought to support dynamic, general
337 matching that would be fast in realistic special cases, in particular
338 when all of the matches were microflows, that is, matches that specify
339 every field present in a packet, because such matches can be imple‐
340 mented as a single hash table lookup. Contemporary research supported
341 the feasibility of this approach: the number of microflows in a campus
342 network had been measured to peak at about 10,000 [Casado, section
343 3.2]. (Calculations show that this can only be true in a lightly loaded
344 network [Pepelnjak].)
345 As a result, OpenFlow 1.0 required switches to treat microflow matches
347 as the highest possible priority. This let software switches perform
348 the microflow hash table lookup first. Only on failure to match a
349 microflow did the switch need to fall back to checking the more general
350 and presumed slower matches. Also, the OpenFlow 1.0 flow match was min‐
351 imally flexible, with no support for general bitwise matching, partly
352 on the basis that this seemed more likely amenable to relatively effi‐
353 cient software implementation. (CIDR masking for IPv4 addresses was
354 added relatively late in the OpenFlow 1.0 design process.)
355 Microflow matching was later discovered to aid some hardware implemen‐
357 tations. The TCAM chips used for matching in hardware do not support
358 priority in the same way as OpenFlow but instead tie priority to order‐
359 ing [Pagiamtzis]. Thus, adding a new match with a priority between the
360 priorities of existing matches can require reordering an arbitrary num‐
361 ber of TCAM entries. On the other hand, when microflows are highest
362 priority, they can be managed as a set-aside portion of the TCAM
363 entries.
364 The emphasis on matching microflows also led designers to carefully
366 consider the bandwidth requirements between switch and controller: to
367 maximize the number of microflow setups per second, one must minimize
368 the size of each flow’s description. This favored the fixed-length for‐
369 mat in use, because it expressed common TCP and UDP microflows in fewer
370 bytes than more flexible ``type-length-value’’ (TLV) formats. (Early
371 versions of OpenFlow also avoided TLVs in general to head off protocol
372 fragmentation.)
373 Inapplicable Fields
375 OpenFlow 1.0 does not clearly specify how to treat inapplicable fields.
377 The members for inapplicable fields are always present in the match
378 data structure, as are the bits that indicate whether the fields are
379 matched, and the ``correct’’ member and bit values for inapplicable
380 fields is unclear. OpenFlow 1.0 implementations changed their behavior
381 over time as priorities shifted. The early OpenFlow reference implemen‐
382 tation, motivated to make every flow a microflow to enable hashing,
383 treated inapplicable fields as exact matches on a value of 0. Ini‐
384 tially, this behavior was implemented in the reference controller only.
385 Later, the reference switch was also changed to actually force any
387 wildcarded inapplicable fields into exact matches on 0. The latter
388 behavior sometimes caused problems, because the modified flow was the
389 one reported back to the controller later when it queried the flow ta‐
390 ble, and the modifications sometimes meant that the controller could
391 not properly recognize the flow that it had added. In retrospect, per‐
392 haps this problem should have alerted the designers to a design error,
393 but the ability to use a single hash table was held to be more impor‐
394 tant than almost every other consideration at the time.
395 When more flexible match formats were introduced much later, they dis‐
397 allowed any mention of inapplicable fields as part of a match. This
398 raised the question of how to translate between this new format and the
399 OpenFlow 1.0 fixed format. It seemed somewhat inconsistent and backward
400 to treat fields as exact-match in one format and forbid matching them
401 in the other, so instead the treatment of inapplicable fields in the
402 fixed-length format was changed from exact match on 0 to wildcarding.
403 (A better classifier had by now eliminated software performance prob‐
404 lems with wildcards.)
405 The OpenFlow 1.0.1 errata (released only in 2012) added some additional
407 explanation [OpenFlow 1.0.1, section 3.4], but it did not mandate spe‐
408 cific behavior because of variation among implementations.
409 OpenFlow 1.1
411 The OpenFlow 1.1 protocol match format was designed as a
413 type/length/value (TLV) format to allow for future flexibility. The
414 specification standardized only a single type OFPMT_STANDARD (0) with a
415 fixed-size payload, described here. The additional fields and bitwise
416 masks in OpenFlow 1.1 cause this match structure to be over twice as
417 large as in OpenFlow 1.0, 88 bytes versus 40.
418 OpenFlow 1.1 added support for the following fields:
420 · SCTP source and destination port.
422 · MPLS label and traffic control (TC) fields.
424 · One 64-bit register (named ``metadata’’).
426 OpenFlow 1.1 increased the width of the ingress port number field (and
428 all other port numbers in the protocol) from 16 bits to 32 bits.
429 OpenFlow 1.1 increased matching flexibility by introducing arbitrary
431 bitwise matching on Ethernet and IPv4 address fields and on the new
432 ``metadata’’ register field. Switches were not required to support all
433 possible masks [OpenFlow 1.1, section 4.3].
434 By a strict reading of the specification, OpenFlow 1.1 removed support
436 for matching ICMPv4 type and code [OpenFlow 1.1, section A.2.3], but
437 this is likely an editing error because ICMP matching is described
438 elsewhere [OpenFlow 1.1, Table 3, Table 4, Figure 4]. Open vSwitch does
439 support ICMPv4 type and code matching with OpenFlow 1.1.
440 OpenFlow 1.1 avoided the pitfalls of inapplicable fields that OpenFlow
442 1.0 encountered, by requiring the switch to ignore the specified field
443 values [OpenFlow 1.1, section A.2.3]. It also implied that the switch
444 should ignore the bits that indicate whether to match inapplicable
445 fields.
446 Physical Ingress Port
448 OpenFlow 1.1 introduced a new pseudo-field, the physical ingress port.
450 The physical ingress port is only a pseudo-field because it cannot be
451 used for matching. It appears only one place in the protocol, in the
452 ``packet-in’’ message that passes a packet received at the switch to an
453 OpenFlow controller.
454 A packet’s ingress port and physical ingress port are identical except
456 for packets processed by a switch feature such as bonding or tunneling
457 that makes a packet appear to arrive on a ``virtual’’ port associated
458 with the bond or the tunnel. For such packets, the ingress port is the
459 virtual port and the physical ingress port is, naturally, the physical
460 port. Open vSwitch implements both bonding and tunneling, but its bond‐
461 ing implementation does not use virtual ports and its tunnels are typi‐
462 cally not on the same OpenFlow switch as their physical ingress ports
463 (which need not be part of any switch), so the ingress port and physi‐
464 cal ingress port are always the same in Open vSwitch.
465 OpenFlow 1.2
467 OpenFlow 1.2 abandoned the fixed-length approach to matching. One rea‐
469 son was size, since adding support for IPv6 address matching (now seen
470 as important), with bitwise masks, would have added 64 bytes to the
471 match length, increasing it from 88 bytes in OpenFlow 1.1 to over 150
472 bytes. Extensibility had also become important as controller writers
473 increasingly wanted support for new fields without having to change
474 messages throughout the OpenFlow protocol. The challenges of carefully
475 defining fixed-length matches to avoid problems with inapplicable
476 fields had also become clear over time.
477 Therefore, OpenFlow 1.2 adopted a flow format using a flexible type-
479 length-value (TLV) representation, in which each TLV expresses a match
480 on one field. These TLVs were in turn encapsulated inside the outer TLV
481 wrapper introduced in OpenFlow 1.1 with the new identifier OFPMT_OXM
482 (1). (This wrapper fulfilled its intended purpose of reducing the
483 amount of churn in the protocol when changing match formats; some mes‐
484 sages that included matches remained unchanged from OpenFlow 1.1 to 1.2
485 and later versions.)
486 OpenFlow 1.2 added support for the following fields:
488 · ARP hardware addresses (SHA and THA).
490 · IPv4 ECN.
492 · IPv6 source and destination addresses, flow label, DSCP,
494 ECN, and protocol.
495 · TCP, UDP, and SCTP port numbers when encapsulated inside
497 IPv6.
498 · ICMPv6 type and code.
500 · ICMPv6 Neighbor Discovery target address and source and
502 target Ethernet addresses.
503 The OpenFlow 1.2 format, called OXM (OpenFlow Extensible Match), was
505 modeled closely on an extension to OpenFlow 1.0 introduced in Open
506 vSwitch 1.1 called NXM (Nicira Extended Match). Each OXM or NXM TLV has
507 the following format:
508 type
510 <---------------->
511 16 7 1 8 length bytes
512 +------------+-----+--+------+ +------------+
513 |vendor/class|field|HM|length| | body |
514 +------------+-----+--+------+ +------------+
515 The most significant 16 bits of the NXM or OXM header, called vendor by
518 NXM and class by OXM, identify an organization permitted to allocate
519 identifiers for fields. NXM allocates only two vendors, 0x0000 for
520 fields supported by OpenFlow 1.0 and 0x0001 for fields implemented as
521 an Open vSwitch extension. OXM assigns classes as follows:
522 0x0000 (OFPXMC_NXM_0).
524 0x0001 (OFPXMC_NXM_1).
525 Reserved for NXM compatibility.
526 0x0002 to 0x7fff
528 Reserved for allocation to ONF members, but none yet
529 assigned.
530 0x8000 (OFPXMC_OPENFLOW_BASIC)
532 Used for most standard OpenFlow fields.
533 0x8001 (OFPXMC_PACKET_REGS)
535 Used for packet register fields in OpenFlow 1.5 and later.
536 0x8002 to 0xfffe
538 Reserved for the OpenFlow specification.
539 0xffff (OFPXMC_EXPERIMENTER)
541 Experimental use.
542 When class is 0xffff, the OXM header is extended to 64 bits by using
544 the first 32 bits of the body as an experimenter field whose most sig‐
545 nificant byte is zero and whose remaining bytes are an Organizationally
546 Unique Identifier (OUI) assigned by the IEEE [IEEE OUI], as shown
547 below.
548 type experimenter
550 <----------> <---------->
551 16 7 1 8 8 24 (length - 4) bytes
552 +------+-----+--+------+ +------+-----+ +------------------+
553 |class |field|HM|length| | zero | OUI | | body |
554 +------+-----+--+------+ +------+-----+ +------------------+
555 0xffff 0x00
556 OpenFlow says that support for experimenter fields is optional. Open
559 vSwitch 2.4 and later does support them, so that it can support the
560 following experimenter classes:
561 0x4f4e4600 (ONFOXM_ET)
563 Used by official Open Networking Foundation extensions in
564 OpenFlow 1.3 and later. e.g. [TCP Flags Match Field
565 Extension].
566 0x005ad650 (NXOXM_NSH)
568 Used by Open vSwitch for NSH extensions, in the absence
569 of an official ONF-assigned class. (This OUI is randomly
570 generated.)
571 Taken as a unit, class (or vendor), field, and experimenter (when
573 present) uniquely identify a particular field.
574 When hasmask (abbreviated HM above) is 0, the OXM is an exact match on
576 an entire field. In this case, the body (excluding the experimenter
577 field, if present) is a single value to be matched.
578 When hasmask is 1, the OXM is a bitwise match. The body (excluding the
580 experimenter field) consists of a value to match, followed by the bit‐
581 wise mask to apply. A 1-bit in the mask indicates that the correspond‐
582 ing bit in the value should be matched and a 0-bit that it should be
583 ignored. For example, for an IP address field, a value of 192.168.0.0
584 followed by a mask of 255.255.0.0 would match addresses in the
585 196.168.0.0/16 subnet.
586 · Some fields might not support masking at all, and some
588 fields that do support masking might restrict it to cer‐
589 tain patterns. For example, fields that have IP address
590 values might be restricted to CIDR masks. The descrip‐
591 tions of individual fields note these restrictions.
592 · An OXM TLV with a mask that is all zeros is not useful
594 (although it is not forbidden), because it is has the
595 same effect as omitting the TLV entirely.
596 · It is not meaningful to pair a 0-bit in an OXM mask with
598 a 1-bit in its value, and Open vSwitch rejects such an
599 OXM with the error OFPBMC_BAD_WILDCARDS, as required by
600 OpenFlow 1.3 and later.
601 The length identifies the number of bytes in the body, including the
603 4-byte experimenter header, if it is present. Each OXM TLV has a fixed
604 length; that is, given class, field, experimenter (if present), and
605 hasmask, length is a constant. The length is included explicitly to
606 allow software to minimally parse OXM TLVs of unknown types.
607 OXM TLVs must be ordered so that a field’s prerequisites are satisfied
609 before it is parsed. For example, an OXM TLV that matches on the IPv4
610 source address field is only allowed following an OXM TLV that matches
611 on the Ethertype for IPv4. Similarly, an OXM TLV that matches on the
612 TCP source port must follow a TLV that matches an Ethertype of IPv4 or
613 IPv6 and one that matches an IP protocol of TCP (in that order). The
614 order of OXM TLVs is not otherwise restricted; no canonical ordering is
615 defined.
616 A given field may be matched only once in a series of OXM TLVs.
618 OpenFlow 1.3
620 OpenFlow 1.3 showed OXM to be largely successful, by adding new fields
622 without making any changes to how flow matches otherwise worked. It
623 added OXMs for the following fields supported by Open vSwitch:
624 · Tunnel ID for ports associated with e.g. VXLAN or keyed
626 GRE.
627 · MPLS ``bottom of stack’’ (BOS) bit.
629 OpenFlow 1.3 also added OXMs for the following fields not documented
631 here and not yet implemented by Open vSwitch:
632 · IPv6 extension header handling.
634 · PBB I-SID.
636 OpenFlow 1.4
638 OpenFlow 1.4 added OXMs for the following fields not documented here
640 and not yet implemented by Open vSwitch:
641 · PBB UCA.
643 OpenFlow 1.5
645 OpenFlow 1.5 added OXMs for the following fields supported by Open
647 vSwitch:
648 · Packet type.
650 · TCP flags.
652 · Packet registers.
654 · The output port in the OpenFlow action set.
656
658 The following sections document the fields that Open vSwitch supports.
659 Each section provides introductory material on a group of related
660 fields, followed by information on each individual field. In addition
661 to field-specific information, each field begins with a table with
662 entries for the following important properties:
663 Name The field’s name, used for parsing and formatting the
665 field, e.g. in ovs-ofctl commands. For historical rea‐
666 sons, some fields have an additional name that is
667 accepted as an alternative in parsing. This name, when
668 there is one, is listed as well, e.g. ``tun (aka tun‐
669 nel_id).’’
670 Width The field’s width, always a multiple of 8 bits. Some
672 fields don’t use all of the bits, so this may be accompa‐
673 nied by an explanation. For example, OpenFlow embeds the
674 2-bit IP ECN field as as the low bits in an 8-bit byte,
675 and so its width is expressed as ``8 bits (only the
676 least-significant 2 bits may be nonzero).’’
677 Format How a value for the field is formatted or parsed by,
679 e.g., ovs-ofctl. Some possibilities are generic:
680 decimal
682 Formats as a decimal number. On input, accepts
683 decimal numbers or hexadecimal numbers prefixed by
684 0x.
685 hexadecimal
687 Formats as a hexadecimal number prefixed by 0x. On
688 input, accepts decimal numbers or hexadecimal num‐
689 bers prefixed by 0x. (The default for parsing is
690 not hexadecimal: only a 0x prefix causes input to
691 be treated as hexadecimal.)
692 Ethernet
694 Formats and accepts the common Ethernet address
695 format xx:xx:xx:xx:xx:xx.
696 IPv4 Formats and accepts the dotted-quad format
698 a.b.c.d. For bitwise matches, formats and accepts
699 address/length CIDR notation in addition to
700 address/mask.
701 IPv6 Formats and accepts the common IPv6 address for‐
703 mats, plus CIDR notation for bitwise matches.
704 OpenFlow 1.0 port
706 Accepts 16-bit port numbers in decimal, plus Open‐
707 Flow well-known port names (e.g. IN_PORT) in
708 uppercase or lowercase.
709 OpenFlow 1.1+ port
711 Same syntax as OpenFlow 1.0 ports but for 32-bit
712 OpenFlow 1.1+ port number fields.
713 Other, field-specific formats are explained along with
715 their fields.
716 Masking
718 For most fields, this says ``arbitrary bitwise masks,’’
719 meaning that a flow may match any combination of bits in
720 the field. Some fields instead say ``exact match only,’’
721 which means that a flow that matches on this field must
722 match on the whole field instead of just certain bits.
723 Either way, this reports masking support for the latest
724 version of Open vSwitch using OXM or NXM (that is, either
725 OpenFlow 1.2+ or OpenFlow 1.0 plus Open vSwitch NXM
726 extensions). In particular, OpenFlow 1.0 (without NXM)
727 and 1.1 don’t always support masking even if Open vSwitch
728 itself does; refer to the OpenFlow 1.0 and OpenFlow 1.1
729 rows to learn about masking with these protocol versions.
730 Prerequisites
732 Requirements that must be met to match on this field. For
733 example, ip_src has IPv4 as a prerequisite, meaning that
734 a match must include eth_type=0x0800 to match on the IPv4
735 source address. The following prerequisites, with their
736 requirements, are currently in use:
737 none (no requirements)
739 VLAN VID
741 vlan_tci=0x1000/0x1000 (i.e. a VLAN header is
742 present)
743 ARP eth_type=0x0806 (ARP) or eth_type=0x8035 (RARP)
745 IPv4 eth_type=0x0800
747 IPv6 eth_type=0x86dd
749 IPv4/IPv6
751 IPv4 or IPv6
752 MPLS eth_type=0x8847 or eth_type=0x8848
754 TCP IPv4/IPv6 and ip_proto=6
756 UDP IPv4/IPv6 and ip_proto=17
758 SCTP IPv4/IPv6 and ip_proto=132
760 ICMPv4 IPv4 and ip_proto=1
762 ICMPv6 IPv6 and ip_proto=58
764 ND solicit
766 ICMPv6 and icmp_type=135 and icmp_code=0
767 ND advert
769 ICMPv6 and icmp_type=136 and icmp_code=0
770 ND ND solicit or ND advert
772 The TCP, UDP, and SCTP prerequisites also have the spe‐
774 cial requirement that nw_frag is not being used to select
775 ``later fragments.’’ This is because only the first frag‐
776 ment of a fragmented IPv4 or IPv6 datagram contains the
777 TCP or UDP header.
778 Access Most fields are ``read/write,’’ which means that common
780 OpenFlow actions like set_field can modify them. Fields
781 that are ``read-only’’ cannot be modified in these gen‐
782 eral-purpose ways, although there may be other ways that
783 actions can modify them.
784 OpenFlow 1.0
786 OpenFlow 1.1
787 These rows report the level of support that OpenFlow 1.0 or
788 OpenFlow 1.1, respectively, has for a field. For OpenFlow
789 1.0, supported fields are reported as either ``yes (exact
790 match only)’’ for fields that do not support any bitwise
791 masking or ``yes (CIDR match only)’’ for fields that sup‐
792 port CIDR masking. OpenFlow 1.1 supported fields report
793 either ``yes (exact match only)’’ or simply ``yes’’ for
794 fields that do support arbitrary masks. These OpenFlow ver‐
795 sions supported a fixed collection of fields that cannot be
796 extended, so many more fields are reported as ``not sup‐
797 ported.’’
798 OXM
800 NXM These rows report the OXM and NXM code points that corre‐
801 spond to a given field. Either or both may be ``none.’’
802 A field that has only an OXM code point is usually one that
804 was standardized before it was added to Open vSwitch. A
805 field that has only an NXM code point is usually one that
806 is not yet standardized. When a field has both OXM and NXM
807 code points, it usually indicates that it was introduced as
808 an Open vSwitch extension under the NXM code point, then
809 later standardized under the OXM code point. A field can
810 have more than one OXM code point if it was standardized in
811 OpenFlow 1.4 or later and additionally introduced as an
812 official ONF extension for OpenFlow 1.3. (A field that has
813 neither OXM nor NXM code point is typically an obsolete
814 field that is supported in some other form using OXM or
815 NXM.)
816 Each code point in these rows is described in the form
818 ``NAME (number) since OpenFlow spec and Open vSwitch ver‐
819 sion,’’ e.g. ``OXM_OF_ETH_TYPE (5) since OpenFlow 1.2 and
820 Open vSwitch 1.7.’’ First, NAME, which specifies a name for
821 the code point, starts with a prefix that designates a
822 class and, in some cases, a vendor, as listed in the fol‐
823 lowing table:
824 Prefix Vendor Class
826 ─────────────── ─────────── ───────
827 NXM_OF (none) 0x0000
828 NXM_NX (none) 0x0001
829 ERICOXM_OF (none) 0x1000
830 OXM_OF (none) 0x8000
831 OXM_OF_PKT_REG (none) 0x8001
832 NXOXM_ET 0x00002320 0xffff
833 NXOXM_NSH 0x005ad650 0xffff
834 ONFOXM_ET 0x4f4e4600 0xffff
835 For more information on OXM/NXM classes and vendors, refer
837 back to OpenFlow 1.2 under Evolution of OpenFlow Fields.
838 The number is the field number within the class and vendor.
839 The OpenFlow spec is the version of OpenFlow that standard‐
840 ized the code point. It is omitted for NXM code points
841 because they are nonstandard. The version is the version of
842 Open vSwitch that first supported the code point.
843
845 Summary:
846 Name Bytes Mask RW? Prereqs NXM/OXM Support
847 ──────── ────── ───── ──── ──────── ────────────────
848 conj_id 4 no no none OVS 2.4+
849 An individual OpenFlow flow can match only a single value for each
851 field. However, situations often arise where one wants to match one of
852 a set of values within a field or fields. For matching a single field
853 against a set, it is straightforward and efficient to add multiple
854 flows to the flow table, one for each value in the set. For example,
855 one might use the following flows to send packets with IP source
856 address a, b, c, or d to the OpenFlow controller:
857 ip,ip_src=a actions=controller
859 ip,ip_src=b actions=controller
860 ip,ip_src=c actions=controller
861 ip,ip_src=d actions=controller
862 Similarly, these flows send packets with IP destination address e, f,
865 g, or h to the OpenFlow controller:
866 ip,ip_dst=e actions=controller
868 ip,ip_dst=f actions=controller
869 ip,ip_dst=g actions=controller
870 ip,ip_dst=h actions=controller
871 Installing all of the above flows in a single flow table yields a dis‐
874 junctive effect: a packet is sent to the controller if ip_src ∈
875 {a,b,c,d} or ip_dst ∈ {e,f,g,h} (or both). (Pedantically, if both of
876 the above sets of flows are present in the flow table, they should have
877 different priorities, because OpenFlow says that the results are unde‐
878 fined when two flows with same priority can both match a single
879 packet.)
880 Suppose, on the other hand, one wishes to match conjunctively, that is,
882 to send a packet to the controller only if both ip_src ∈ {a,b,c,d} and
883 ip_dst ∈ {e,f,g,h}. This requires 4 × 4 = 16 flows, one for each possi‐
884 ble pairing of ip_src and ip_dst. That is acceptable for our small
885 example, but it does not gracefully extend to larger sets or greater
886 numbers of dimensions.
887 The conjunction action is a solution for conjunctive matches that is
889 built into Open vSwitch. A conjunction action ties groups of individual
890 OpenFlow flows into higher-level ``conjunctive flows’’. Each group cor‐
891 responds to one dimension, and each flow within the group matches one
892 possible value for the dimension. A packet that matches one flow from
893 each group matches the conjunctive flow.
894 To implement a conjunctive flow with conjunction, assign the conjunc‐
896 tive flow a 32-bit id, which must be unique within an OpenFlow table.
897 Assign each of the n ≥ 2 dimensions a unique number from 1 to n; the
898 ordering is unimportant. Add one flow to the OpenFlow flow table for
899 each possible value of each dimension with conjunction(id, k/n) as the
900 flow’s actions, where k is the number assigned to the flow’s dimension.
901 Together, these flows specify the conjunctive flow’s match condition.
902 When the conjunctive match condition is met, Open vSwitch looks up one
903 more flow that specifies the conjunctive flow’s actions and receives
904 its statistics. This flow is found by setting conj_id to the specified
905 id and then again searching the flow table.
906 The following flows provide an example. Whenever the IP source is one
908 of the values in the flows that match on the IP source (dimension 1 of
909 2), and the IP destination is one of the values in the flows that match
910 on IP destination (dimension 2 of 2), Open vSwitch searches for a flow
911 that matches conj_id against the conjunction ID (1234), finding the
912 first flow listed below.
913 conj_id=1234 actions=controller
915 ip,ip_src=10.0.0.1 actions=conjunction(1234, 1/2)
916 ip,ip_src=10.0.0.4 actions=conjunction(1234, 1/2)
917 ip,ip_src=10.0.0.6 actions=conjunction(1234, 1/2)
918 ip,ip_src=10.0.0.7 actions=conjunction(1234, 1/2)
919 ip,ip_dst=10.0.0.2 actions=conjunction(1234, 2/2)
920 ip,ip_dst=10.0.0.5 actions=conjunction(1234, 2/2)
921 ip,ip_dst=10.0.0.7 actions=conjunction(1234, 2/2)
922 ip,ip_dst=10.0.0.8 actions=conjunction(1234, 2/2)
923 Many subtleties exist:
926 · In the example above, every flow in a single dimension
928 has the same form, that is, dimension 1 matches on ip_src
929 and dimension 2 on ip_dst, but this is not a requirement.
930 Different flows within a dimension may match on different
931 bits within a field (e.g. IP network prefixes of differ‐
932 ent lengths, or TCP/UDP port ranges as bitwise matches),
933 or even on entirely different fields (e.g. to match pack‐
934 ets for TCP source port 80 or TCP destination port 80).
935 · The flows within a dimension can vary their matches
937 across more than one field, e.g. to match only specific
938 pairs of IP source and destination addresses or L4 port
939 numbers.
940 · A flow may have multiple conjunction actions, with dif‐
942 ferent id values. This is useful for multiple conjunctive
943 flows with overlapping sets. If one conjunctive flow
944 matches packets with both ip_src ∈ {a,b} and ip_dst ∈
945 {d,e} and a second conjunctive flow matches ip_src ∈
946 {b,c} and ip_dst ∈ {f,g}, for example, then the flow that
947 matches ip_src=b would have two conjunction actions, one
948 for each conjunctive flow. The order of conjunction
949 actions within a list of actions is not significant.
950 · A flow with conjunction actions may also include note
952 actions for annotations, but not any other kind of
953 actions. (They would not be useful because they would
954 never be executed.)
955 · All of the flows that constitute a conjunctive flow with
957 a given id must have the same priority. (Flows with the
958 same id but different priorities are currently treated as
959 different conjunctive flows, that is, currently id values
960 need only be unique within an OpenFlow table at a given
961 priority. This behavior isn’t guaranteed to stay the same
962 in later releases, so please use id values unique within
963 an OpenFlow table.)
964 · Conjunctive flows must not overlap with each other, at a
966 given priority, that is, any given packet must be able to
967 match at most one conjunctive flow at a given priority.
968 Overlapping conjunctive flows yield unpredictable
969 results.
970 · Following a conjunctive flow match, the search for the
972 flow with conj_id=id is done in the same general-purpose
973 way as other flow table searches, so one can use flows
974 with conj_id=id to act differently depending on circum‐
975 stances. (One exception is that the search for the
976 conj_id=id flow itself ignores conjunctive flows, to
977 avoid recursion.) If the search with conj_id=id fails,
978 Open vSwitch acts as if the conjunctive flow had not
979 matched at all, and continues searching the flow table
980 for other matching flows.
981 · OpenFlow prerequisite checking occurs for the flow with
983 conj_id=id in the same way as any other flow, e.g. in an
984 OpenFlow 1.1+ context, putting a mod_nw_src action into
985 the example above would require adding an ip match, like
986 this:
987 conj_id=1234,ip actions=mod_nw_src:1.2.3.4,controller
989 · OpenFlow prerequisite checking also occurs for the indi‐
992 vidual flows that comprise a conjunctive match in the
993 same way as any other flow.
994 · The flows that constitute a conjunctive flow do not have
996 useful statistics. They are never updated with byte or
997 packet counts, and so on. (For such a flow, therefore,
998 the idle and hard timeouts work much the same way.)
999 · Sometimes there is a choice of which flows include a par‐
1001 ticular match. For example, suppose that we added an
1002 extra constraint to our example, to match on ip_src ∈
1003 {a,b,c,d} and ip_dst ∈ {e,f,g,h} and tcp_dst = i. One way
1004 to implement this is to add the new constraint to the
1005 conj_id flow, like this:
1006 conj_id=1234,tcp,tcp_dst=i actions=mod_nw_src:1.2.3.4,controller
1008 but this is not recommended because of the cost of the
1011 extra flow table lookup. Instead, add the constraint to
1012 the individual flows, either in one of the dimensions or
1013 (slightly better) all of them.
1014 · A conjunctive match must have n ≥ 2 dimensions (otherwise
1016 a conjunctive match is not necessary). Open vSwitch
1017 enforces this.
1018 · Each dimension within a conjunctive match should ordinar‐
1020 ily have more than one flow. Open vSwitch does not
1021 enforce this.
1022 Conjunction ID Field
1024 Name: conj_id
1026 Width: 32 bits
1027 Format: decimal
1028 Masking: not maskable
1029 Prerequisites: none
1030 Access: read-only
1031 OpenFlow 1.0: not supported
1032 OpenFlow 1.1: not supported
1033 OXM: none
1034 NXM: NXM_NX_CONJ_ID (37) since Open vSwitch 2.4
1035 Used for conjunctive matching. See above for more information.
1037
1039 Summary:
1040 Name Bytes Mask RW? Prereqs NXM/OXM Support
1041 ───────────────────── ──────────────── ───── ──── ──────── ─────────────────────
1042 tun_id aka tunnel_id 8 yes yes none OF 1.3+ and OVS 1.1+
1043 tun_src 4 yes yes none OVS 2.0+
1044 tun_dst 4 yes yes none OVS 2.0+
1045 tun_ipv6_src 16 yes yes none OVS 2.5+
1046 tun_ipv6_dst 16 yes yes none OVS 2.5+
1047 tun_gbp_id 2 yes yes none OVS 2.4+
1048 tun_gbp_flags 1 yes yes none OVS 2.4+
1049 tun_erspan_ver 1 (low 4 bits) yes yes none OVS 2.10+
1050 tun_erspan_idx 4 (low 20 bits) yes yes none OVS 2.10+
1052 tun_erspan_dir 1 (low 1 bits) yes yes none OVS 2.10+
1053 tun_erspan_hwid 1 (low 6 bits) yes yes none OVS 2.10+
1054 tun_metadata0 124 yes yes none OVS 2.5+
1055 tun_metadata1 124 yes yes none OVS 2.5+
1056 tun_metadata2 124 yes yes none OVS 2.5+
1057 tun_metadata3 124 yes yes none OVS 2.5+
1058 tun_metadata4 124 yes yes none OVS 2.5+
1059 tun_metadata5 124 yes yes none OVS 2.5+
1060 tun_metadata6 124 yes yes none OVS 2.5+
1061 tun_metadata7 124 yes yes none OVS 2.5+
1062 tun_metadata8 124 yes yes none OVS 2.5+
1063 tun_metadata9 124 yes yes none OVS 2.5+
1064 tun_metadata10 124 yes yes none OVS 2.5+
1066 tun_metadata11 124 yes yes none OVS 2.5+
1067 tun_metadata12 124 yes yes none OVS 2.5+
1068 tun_metadata13 124 yes yes none OVS 2.5+
1069 tun_metadata14 124 yes yes none OVS 2.5+
1070 tun_metadata15 124 yes yes none OVS 2.5+
1071 tun_metadata16 124 yes yes none OVS 2.5+
1072 tun_metadata17 124 yes yes none OVS 2.5+
1073 tun_metadata18 124 yes yes none OVS 2.5+
1074 tun_metadata19 124 yes yes none OVS 2.5+
1075 tun_metadata20 124 yes yes none OVS 2.5+
1076 tun_metadata21 124 yes yes none OVS 2.5+
1077 tun_metadata22 124 yes yes none OVS 2.5+
1078 tun_metadata23 124 yes yes none OVS 2.5+
1080 tun_metadata24 124 yes yes none OVS 2.5+
1081 tun_metadata25 124 yes yes none OVS 2.5+
1082 tun_metadata26 124 yes yes none OVS 2.5+
1083 tun_metadata27 124 yes yes none OVS 2.5+
1084 tun_metadata28 124 yes yes none OVS 2.5+
1085 tun_metadata29 124 yes yes none OVS 2.5+
1086 tun_metadata30 124 yes yes none OVS 2.5+
1087 tun_metadata31 124 yes yes none OVS 2.5+
1088 tun_metadata32 124 yes yes none OVS 2.5+
1089 tun_metadata33 124 yes yes none OVS 2.5+
1090 tun_metadata34 124 yes yes none OVS 2.5+
1091 tun_metadata35 124 yes yes none OVS 2.5+
1092 tun_metadata36 124 yes yes none OVS 2.5+
1094 tun_metadata37 124 yes yes none OVS 2.5+
1095 tun_metadata38 124 yes yes none OVS 2.5+
1096 tun_metadata39 124 yes yes none OVS 2.5+
1097 tun_metadata40 124 yes yes none OVS 2.5+
1098 tun_metadata41 124 yes yes none OVS 2.5+
1099 tun_metadata42 124 yes yes none OVS 2.5+
1100 tun_metadata43 124 yes yes none OVS 2.5+
1101 tun_metadata44 124 yes yes none OVS 2.5+
1102 tun_metadata45 124 yes yes none OVS 2.5+
1103 tun_metadata46 124 yes yes none OVS 2.5+
1104 tun_metadata47 124 yes yes none OVS 2.5+
1105 tun_metadata48 124 yes yes none OVS 2.5+
1106 tun_metadata49 124 yes yes none OVS 2.5+
1108 tun_metadata50 124 yes yes none OVS 2.5+
1109 tun_metadata51 124 yes yes none OVS 2.5+
1110 tun_metadata52 124 yes yes none OVS 2.5+
1111 tun_metadata53 124 yes yes none OVS 2.5+
1112 tun_metadata54 124 yes yes none OVS 2.5+
1113 tun_metadata55 124 yes yes none OVS 2.5+
1114 tun_metadata56 124 yes yes none OVS 2.5+
1115 tun_metadata57 124 yes yes none OVS 2.5+
1116 tun_metadata58 124 yes yes none OVS 2.5+
1117 tun_metadata59 124 yes yes none OVS 2.5+
1118 tun_metadata60 124 yes yes none OVS 2.5+
1119 tun_metadata61 124 yes yes none OVS 2.5+
1120 tun_metadata62 124 yes yes none OVS 2.5+
1122 tun_metadata63 124 yes yes none OVS 2.5+
1123 tun_flags 2 (low 1 bits) yes yes none OVS 2.5+
1124 The fields in this group relate to tunnels, which Open vSwitch supports
1126 in several forms (GRE, VXLAN, and so on). Most of these fields do
1127 appear in the wire format of a packet, so they are data fields from
1128 that point of view, but they are metadata from an OpenFlow flow table
1129 point of view because they do not appear in packets that are forwarded
1130 to the controller or to ordinary (non-tunnel) output ports.
1131 Open vSwitch supports a spectrum of usage models for mapping tunnels to
1133 OpenFlow ports:
1134 ``Port-based’’ tunnels
1136 In this model, an OpenFlow port represents one tunnel: it
1137 matches a particular type of tunnel traffic between two
1138 IP endpoints, with a particular tunnel key (if keys are
1139 in use). In this situation, in_port suffices to distin‐
1140 guish one tunnel from another, so the tunnel header
1141 fields have little importance for OpenFlow processing.
1142 (They are still populated and may be used if it is conve‐
1143 nient.) The tunnel header fields play no role in sending
1144 packets out such an OpenFlow port, either, because the
1145 OpenFlow port itself fully specifies the tunnel headers.
1146 The following Open vSwitch commands create a bridge
1148 br-int, add port tap0 to the bridge as OpenFlow port 1,
1149 establish a port-based GRE tunnel between the local host
1150 and remote IP 192.168.1.1 using GRE key 5001 as OpenFlow
1151 port 2, and arranges to forward all traffic from tap0 to
1152 the tunnel and vice versa:
1153 ovs-vsctl add-br br-int
1155 ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1156 ovs-vsctl add-port br-int gre0 -- \
1157 set interface gre0 ofport_request=2 type=gre \
1158 options:remote_ip=192.168.1.1 options:key=5001
1159 ovs-ofctl add-flow br-int in_port=1,actions=2
1160 ovs-ofctl add-flow br-int in_port=2,actions=1
1161 ``Flow-based’’ tunnels
1164 In this model, one OpenFlow port represents all possible
1165 tunnels of a given type with an endpoint on the current
1166 host, for example, all GRE tunnels. In this situation,
1167 in_port only indicates that traffic was received on the
1168 particular kind of tunnel. This is where the tunnel
1169 header fields are most important: they allow the OpenFlow
1170 tables to discriminate among tunnels based on their IP
1171 endpoints or keys. Tunnel header fields also determine
1172 the IP endpoints and keys of packets sent out such a tun‐
1173 nel port.
1174 The following Open vSwitch commands create a bridge
1176 br-int, add port tap0 to the bridge as OpenFlow port 1,
1177 establish a flow-based GRE tunnel port 3, and arranges to
1178 forward all traffic from tap0 to remote IP 192.168.1.1
1179 over a GRE tunnel with key 5001 and vice versa:
1180 ovs-vsctl add-br br-int
1182 ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1183 ovs-vsctl add-port br-int allgre -- \
1184 set interface allgre ofport_request=3 type=gre \
1185 options:remote_ip=flow options:key=flow
1186 ovs-ofctl add-flow br-int \
1187 ’in_port=1 actions=set_tunnel:5001,set_field:192.168.1.1->tun_dst,3’
1188 ovs-ofctl add-flow br-int ’in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1’
1189 Mixed models.
1192 One may define both flow-based and port-based tunnels at
1193 the same time. For example, it is valid and possibly use‐
1194 ful to create and configure both gre0 and allgre tunnel
1195 ports described above.
1196 Traffic is attributed on ingress to the most specific
1198 matching tunnel. For example, gre0 is more specific than
1199 allgre. Therefore, if both exist, then gre0 will be the
1200 ingress port for any GRE traffic received from
1201 192.168.1.1 with key 5001.
1202 On egress, traffic may be directed to any appropriate
1204 tunnel port. If both gre0 and allgre are configured as
1205 already described, then the actions 2 and set_tun‐
1206 nel:5001,set_field:192.168.1.1->tun_dst,3 send the same
1207 tunnel traffic.
1208 Intermediate models.
1210 Ports may be configured as partially flow-based. For
1211 example, one may define an OpenFlow port that represents
1212 tunnels between a pair of endpoints but leaves the flow
1213 table to discriminate on the flow key.
1214 ovs-vswitchd.conf.db(5) describes all the details of tunnel configura‐
1216 tion.
1217 These fields do not have any prerequisites, which means that a flow may
1219 match on any or all of them, in any combination.
1220 These fields are zeros for packets that did not arrive on a tunnel.
1222 Tunnel ID Field
1224 Name: tun_id (aka tunnel_id)
1226 Width: 64 bits
1227 Format: hexadecimal
1228 Masking: arbitrary bitwise masks
1229 Prerequisites: none
1230 Access: read/write
1231 OpenFlow 1.0: not supported
1232 OpenFlow 1.1: not supported
1234 OXM: OXM_OF_TUNNEL_ID [22m(38) since OpenFlow 1.3 and Open
1235 vSwitch 1.10
1236 NXM: NXM_NX_TUN_ID (16) since Open vSwitch 1.1
1237 Many kinds of tunnels support a tunnel ID:
1239 · VXLAN and Geneve have a 24-bit virtual network identifier
1241 (VNI).
1242 · LISP has a 24-bit instance ID.
1244 · GRE has an optional 32-bit key.
1246 · STT has a 64-bit key.
1248 · ERSPAN has a 10-bit key (Session ID).
1250 When a packet is received from a tunnel, this field holds the tunnel ID
1252 in its least significant bits, zero-extended to fit. This field is zero
1253 if the tunnel does not support an ID, or if no ID is in use for a tun‐
1254 nel type that has an optional ID, or if an ID of zero received, or if
1255 the packet was not received over a tunnel.
1256 When a packet is output to a tunnel port, the tunnel configuration
1258 determines whether the tunnel ID is taken from this field or bound to a
1259 fixed value. See the earlier description of ``port-based’’ and ``flow-
1260 based’’ tunnels for more information.
1261 The following diagram shows the origin of this field in a typical keyed
1263 GRE tunnel:
1264 Ethernet IPv4 GRE Ethernet
1266 <-----------> <---------------> <------------> <---------->
1267 48 48 16 8 32 32 16 16 32 48 48 16
1268 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1269 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1270 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1271 0x800 47 0x6558
1272 Tunnel IPv4 Source Field
1275 Name: tun_src
1277 Width: 32 bits
1278 Format: IPv4
1279 Masking: arbitrary bitwise masks
1280 Prerequisites: none
1281 Access: read/write
1282 OpenFlow 1.0: not supported
1283 OpenFlow 1.1: not supported
1284 OXM: none
1285 NXM: NXM_NX_TUN_IPV4_SRC (31) since Open vSwitch 2.0
1286 When a packet is received from a tunnel, this field is the source
1288 address in the outer IP header of the tunneled packet. This field is
1289 zero if the packet was not received over a tunnel.
1290 When a packet is output to a flow-based tunnel port, this field influ‐
1292 ences the IPv4 source address used to send the packet. If it is zero,
1293 then the kernel chooses an appropriate IP address based using the rout‐
1294 ing table.
1295 The following diagram shows the origin of this field in a typical keyed
1297 GRE tunnel:
1298 Ethernet IPv4 GRE Ethernet
1300 <-----------> <---------------> <------------> <---------->
1301 48 48 16 8 32 32 16 16 32 48 48 16
1302 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1303 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1304 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1305 0x800 47 0x6558
1306 Tunnel IPv4 Destination Field
1309 Name: tun_dst
1311 Width: 32 bits
1312 Format: IPv4
1313 Masking: arbitrary bitwise masks
1314 Prerequisites: none
1315 Access: read/write
1316 OpenFlow 1.0: not supported
1318 OpenFlow 1.1: not supported
1319 OXM: none
1320 NXM: NXM_NX_TUN_IPV4_DST (32) since Open vSwitch 2.0
1321 When a packet is received from a tunnel, this field is the destination
1323 address in the outer IP header of the tunneled packet. This field is
1324 zero if the packet was not received over a tunnel.
1325 When a packet is output to a flow-based tunnel port, this field speci‐
1327 fies the destination to which the tunnel packet is sent.
1328 The following diagram shows the origin of this field in a typical keyed
1330 GRE tunnel:
1331 Ethernet IPv4 GRE Ethernet
1333 <-----------> <---------------> <------------> <---------->
1334 48 48 16 8 32 32 16 16 32 48 48 16
1335 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1336 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1337 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1338 0x800 47 0x6558
1339 Tunnel IPv6 Source Field
1342 Name: tun_ipv6_src
1344 Width: 128 bits
1346 Format: IPv6
1347 Masking: arbitrary bitwise masks
1348 Prerequisites: none
1349 Access: read/write
1350 OpenFlow 1.0: not supported
1351 OpenFlow 1.1: not supported
1352 OXM: none
1353 NXM: NXM_NX_TUN_IPV6_SRC (109) since Open vSwitch 2.5
1354 Similar to tun_src, but for tunnels over IPv6.
1356 Tunnel IPv6 Destination Field
1358 Name: tun_ipv6_dst
1360 Width: 128 bits
1361 Format: IPv6
1362 Masking: arbitrary bitwise masks
1363 Prerequisites: none
1364 Access: read/write
1365 OpenFlow 1.0: not supported
1366 OpenFlow 1.1: not supported
1367 OXM: none
1368 NXM: NXM_NX_TUN_IPV6_DST (110) since Open vSwitch 2.5
1369 Similar to tun_dst, but for tunnels over IPv6.
1371 VXLAN Group-Based Policy Fields
1373 The VXLAN header is defined as follows [RFC 7348], where the I bit must
1374 be set to 1, unlabeled bits or those labeled reserved must be set to 0,
1375 and Open vSwitch makes the VNI available via tun_id:
1376 VXLAN flags
1378 <------------->
1379 1 1 1 1 1 1 1 1 24 24 8
1380 +-+-+-+-+-+-+-+-+--------+---+--------+
1381 | | | | |I| | | |reserved|VNI|reserved|
1382 +-+-+-+-+-+-+-+-+--------+---+--------+
1383 VXLAN Group-Based Policy [VXLAN Group Policy Option] adds new interpre‐
1386 tations to existing bits in the VXLAN header, reinterpreting it as fol‐
1387 lows, with changes highlighted:
1388 GBP flags
1390 <------------->
1391 1 1 1 1 1 1 1 1 24 24 8
1392 +-+-+-+-+-+-+-+-+---------------+---+--------+
1393 | |D| | |A| | | |group policy ID|VNI|reserved|
1394 +-+-+-+-+-+-+-+-+---------------+---+--------+
1395 Open vSwitch makes GBP fields and flags available through the following
1398 fields. Only packets that arrive over a VXLAN tunnel with the GBP
1399 extension enabled have these fields set. In other packets they are zero
1400 on receive and ignored on transmit.
1401 VXLAN Group-Based Policy ID Field
1403 Name: tun_gbp_id
1405 Width: 16 bits
1406 Format: decimal
1408 Masking: arbitrary bitwise masks
1409 Prerequisites: none
1410 Access: read/write
1411 OpenFlow 1.0: not supported
1412 OpenFlow 1.1: not supported
1413 OXM: none
1414 NXM: NXM_NX_TUN_GBP_ID (38) since Open vSwitch 2.4
1415 For a packet tunneled over VXLAN with the Group-Based Policy (GBP)
1417 extension, this field represents the GBP policy ID, as shown above.
1418 VXLAN Group-Based Policy Flags Field
1420 Name: tun_gbp_flags
1422 Width: 8 bits
1424 Format: hexadecimal
1425 Masking: arbitrary bitwise masks
1426 Prerequisites: none
1427 Access: read/write
1428 OpenFlow 1.0: not supported
1429 OpenFlow 1.1: not supported
1430 OXM: none
1431 NXM: NXM_NX_TUN_GBP_FLAGS (39) since Open vSwitch 2.4
1432 For a packet tunneled over VXLAN with the Group-Based Policy (GBP)
1434 extension, this field represents the GBP policy flags, as shown above.
1435 The field has the format shown below:
1437 GBP Flags
1439 <------------->
1440 1 1 1 1 1 1 1 1
1441 +-+-+-+-+-+-+-+-+
1442 | |D| | |A| | | |
1443 +-+-+-+-+-+-+-+-+
1444 Unlabeled bits are reserved and must be transmitted as 0. The VXLAN GBP
1447 draft defines the other bits’ meanings as:
1448 D (Don’t Learn)
1450 When set, this bit indicates that the egress tunnel end‐
1451 point must not learn the source address of the encapsu‐
1452 lated frame.
1453 A (Applied)
1455 When set, indicates that the group policy has already
1456 been applied to this packet. Devices must not apply poli‐
1457 cies when the A bit is set.
1458 ERSPAN Metadata Fields
1460 These fields provide access to features in the ERSPAN tunneling proto‐
1461 col [ERSPAN], which has two major versions: version 1 (aka type II) and
1462 version 2 (aka type III).
1463 Regardless of version, ERSPAN is encapsulated within a fixed 8-byte GRE
1465 header that consists of a 4-byte GRE base header and a 4-byte sequence
1466 number. The ERSPAN version 1 header format is:
1467 GRE ERSPAN v1 Ethernet
1469 <------------> <---------------------> <---------->
1470 16 16 32 4 18 10 12 20 48 48 16
1471 +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1472 |...| type |seq| |ver|...|session|...|idx| |dst|src|type| ...
1473 +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1474 0x88be 1 tun_id
1475 The ERSPAN version 2 header format is:
1478 GRE ERSPAN v2 Ethernet
1480 <------------> <----------------------------------------> <---------->
1481 16 16 32 4 18 10 32 22 6 1 3 48 48 16
1482 +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1483 |...| type |seq| |ver|...|session|timestamp|...|hwid|dir|...| |dst|src|type| ...
1484 +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1485 0x22eb 2 tun_id 0/1
1486 ERSPAN Version Field
1489 Name: tun_erspan_ver
1491 Width: 8 bits (only the least-significant 4 bits may be nonzero)
1492 Format: decimal
1494 Masking: arbitrary bitwise masks
1495 Prerequisites: none
1496 Access: read/write
1497 OpenFlow 1.0: not supported
1498 OpenFlow 1.1: not supported
1499 OXM: none
1500 NXM: NXOXM_ET_ERSPAN_VER (12) since Open vSwitch 2.10
1501 ERSPAN version number: 1 for version 1, or 2 for version 2.
1503 ERSPAN Index Field
1505 Name: tun_erspan_idx
1507 Width: 32 bits (only the least-significant 20 bits may be nonzero)
1508 Format: hexadecimal
1509 Masking: arbitrary bitwise masks
1510 Prerequisites: none
1512 Access: read/write
1513 OpenFlow 1.0: not supported
1514 OpenFlow 1.1: not supported
1515 OXM: none
1516 NXM: NXOXM_ET_ERSPAN_IDX (11) since Open vSwitch 2.10
1517 This field is a 20-bit index/port number associated with the ERSPAN
1519 traffic’s source port and direction (ingress/egress). This field is
1520 platform dependent.
1521 ERSPAN Direction Field
1523 Name: tun_erspan_dir
1525 Width: 8 bits (only the least-significant 1 bits may be nonzero)
1526 Format: decimal
1527 Masking: arbitrary bitwise masks
1528 Prerequisites: none
1530 Access: read/write
1531 OpenFlow 1.0: not supported
1532 OpenFlow 1.1: not supported
1533 OXM: none
1534 NXM: NXOXM_ET_ERSPAN_DIR (13) since Open vSwitch 2.10
1535 For ERSPAN v2, the mirrored traffic’s direction: 0 for ingress traffic,
1537 1 for egress traffic.
1538 ERSPAN Hardware ID Field
1540 Name: tun_erspan_hwid
1542 Width: 8 bits (only the least-significant 6 bits may be nonzero)
1543 Format: hexadecimal
1544 Masking: arbitrary bitwise masks
1545 Prerequisites: none
1546 Access: read/write
1548 OpenFlow 1.0: not supported
1549 OpenFlow 1.1: not supported
1550 OXM: none
1551 NXM: NXOXM_ET_ERSPAN_HWID (14) since Open vSwitch 2.10
1552 A 6-bit unique identifier of an ERSPAN v2 engine within a system.
1554 Geneve Fields
1556 These fields provide access to additional features in the Geneve tun‐
1557 neling protocol [Geneve]. Their names are somewhat generic in the hope
1558 that the same fields could be reused for other protocols in the future;
1559 for example, the NSH protocol [NSH] supports TLV options whose form is
1560 identical to that for Geneve options.
1561 Generic Tunnel Option 0 Field
1563 Name: tun_metadata0
1566 Width: 992 bits (124 bytes)
1567 Format: hexadecimal
1568 Masking: arbitrary bitwise masks
1569 Prerequisites: none
1570 Access: read/write
1571 OpenFlow 1.0: not supported
1572 OpenFlow 1.1: not supported
1573 OXM: none
1574 NXM: NXM_NX_TUN_METADATA0 (40) since Open vSwitch 2.5
1575 The above information specifically covers generic tunnel option 0, but
1577 Open vSwitch supports 64 options, numbered 0 through 63, whose NXM
1578 field numbers are 40 through 103.
1579 These fields provide OpenFlow access to the generic type-length-value
1581 options defined by the Geneve tunneling protocol or other protocols
1582 with options in the same TLV format as Geneve options. Each of these
1583 options has the following wire format:
1584 header body
1586 <-------------------> <------------------>
1587 16 8 3 5 4×(length - 1) bytes
1588 +-----+----+---+------+--------------------+
1589 |class|type|res|length| value |
1590 +-----+----+---+------+--------------------+
1591 0
1592 Taken together, the class and type in the option format mean that there
1595 are about 16 million distinct kinds of TLV options, too many to give
1596 individual OXM code points. Thus, Open vSwitch requires the user to
1597 define the TLV options of interest, by binding up to 64 TLV options to
1598 generic tunnel option NXM code points. Each option may have up to 124
1599 bytes in its body, the maximum allowed by the TLV format, but bound
1600 options may total at most 252 bytes of body.
1601 Open vSwitch extensions to the OpenFlow protocol bind TLV options to
1603 NXM code points. The ovs-ofctl(8) program offers one way to use these
1604 extensions, e.g. to configure a mapping from a TLV option with class
1605 0xffff, type 0, and a body length of 4 bytes:
1606 ovs-ofctl add-tlv-map br0 "{class=0xffff,type=0,len=4}->tun_metadata0"
1608 Once a TLV option is properly bound, it can be accessed and modified
1611 like any other field, e.g. to send packets that have value 1234 for the
1612 option described above to the controller:
1613 ovs-ofctl add-flow br0 tun_metadata0=1234,actions=controller
1615 An option not received or not bound is matched as all zeros.
1618 Tunnel Flags Field
1620 Name: tun_flags
1622 Width: 16 bits (only the least-significant 1 bits may be nonzero)
1623 Format: tunnel flags
1624 Masking: arbitrary bitwise masks
1625 Prerequisites: none
1626 Access: read/write
1627 OpenFlow 1.0: not supported
1628 OpenFlow 1.1: not supported
1629 OXM: none
1630 NXM: NXM_NX_TUN_FLAGS (104) since Open vSwitch 2.5
1631 Flags indicating various aspects of the tunnel encapsulation.
1633 Matches on this field are most conveniently written in terms of sym‐
1635 bolic names (given in the diagram below), each preceded by either + for
1636 a flag that must be set, or - for a flag that must be unset, without
1637 any other delimiters between the flags. Flags not mentioned are wild‐
1638 carded. For example, tun_flags=+oam matches only OAM packets. Matches
1639 can also be written as flags/mask, where flags and mask are 16-bit num‐
1640 bers in decimal or in hexadecimal prefixed by 0x.
1641 Currently, only one flag is defined:
1643 oam The tunnel protocol indicated that this is an OAM (Opera‐
1645 tions and Management) control packet.
1646 The switch may reject matches against unknown flags.
1648 Newer versions of Open vSwitch may introduce additional flags with new
1650 meanings. It is therefore not recommended to use an exact match on this
1651 field since the behavior of these new flags is unknown and should be
1652 ignored.
1653 For non-tunneled packets, the value is 0.
1656 Summary:
1657 Name Bytes Mask RW? Prereqs NXM/OXM Support
1658 ────────────── ────── ───── ──── ──────── ─────────────────────
1660 in_port 2 no yes none OVS 1.1+
1661 in_port_oxm 4 no yes none OF 1.2+ and OVS 1.7+
1662 skb_priority 4 no no none
1664 pkt_mark 4 yes yes none OVS 2.0+
1665 actset_output 4 no no none OF 1.3+ and OVS 2.4+
1666 packet_type 4 no no none OF 1.5+ and OVS 2.8+
1668 These fields relate to the origin or treatment of a packet, but they
1670 are not extracted from the packet data itself.
1671 Ingress Port Field
1673 Name: in_port
1676 Width: 16 bits
1677 Format: OpenFlow 1.0 port
1678 Masking: not maskable
1680 Prerequisites: none
1681 Access: read/write
1682 OpenFlow 1.0: yes (exact match only)
1684 OpenFlow 1.1: yes (exact match only)
1685 OXM: none
1686 NXM: NXM_OF_IN_PORT (0) since Open vSwitch 1.1
1688 The OpenFlow port on which the packet being processed arrived. This is
1690 a 16-bit field that holds an OpenFlow 1.0 port number. For receiving a
1691 packet, the only values that appear in this field are:
1692 1 through 0xfeff (65,279), inclusive.
1694 Conventional OpenFlow port numbers.
1695 OFPP_LOCAL (0xfffe or 65,534).
1697 The ``local’’ port, which in Open vSwitch is always named
1698 the same as the bridge itself. This represents a connec‐
1699 tion between the switch and the local TCP/IP stack. This
1700 port is where an IP address is most commonly configured
1701 on an Open vSwitch switch.
1702 OpenFlow does not require a switch to have a local port,
1704 but all existing versions of Open vSwitch have always
1705 included a local port. Future Directions: Future versions
1706 of Open vSwitch might be able to optionally omit the
1707 local port, if someone submits code to implement such a
1708 feature.
1709 OFPP_NONE (OpenFlow 1.0) or OFPP_ANY (OpenFlow 1.1+) (0xffff or
1711 65,535).
1712 OFPP_CONTROLLER (0xfffd or 65,533).
1713 When a controller injects a packet into an OpenFlow switch
1714 with a ``packet-out’’ request, it can specify one of these
1715 ingress ports to indicate that the packet was generated
1716 internally rather than having been received on some port.
1717 OpenFlow 1.0 specified OFPP_NONE for this purpose. Despite
1719 that, some controllers used OFPP_CONTROLLER, and some
1720 switches only accepted OFPP_CONTROLLER, so OpenFlow 1.0.2
1721 required support for both ports. OpenFlow 1.1 and later
1722 were more clearly drafted to allow only OFPP_CONTROLLER.
1723 For maximum compatibility, Open vSwitch allows both ports
1724 with all OpenFlow versions.
1725 Values not mentioned above will never appear when receiving a packet,
1727 including the following notable values:
1728 0 Zero is not a valid OpenFlow port number.
1730 OFPP_MAX (0xff00 or 65,280).
1732 This value has only been clearly specified as a valid
1733 port number as of OpenFlow 1.3.3. Before that, its status
1734 was unclear, and so Open vSwitch has never allowed
1735 OFPP_MAX to be used as a port number, so packets will
1736 never be received on this port. (Other OpenFlow switches,
1737 of course, might use it.)
1738 OFPP_UNSET (0xfff7 or 65,527)
1740 OFPP_IN_PORT (0xfff8 or 65,528)
1741 OFPP_TABLE (0xfff9 or 65,529)
1742 OFPP_NORMAL (0xfffa or 65,530)
1743 OFPP_FLOOD (0xfffb or 65,531)
1744 OFPP_ALL (0xfffc or 65,532)
1745 These port numbers are used only in output actions and
1746 never appear as ingress ports.
1747 Most of these port numbers were defined in OpenFlow 1.0,
1749 but OFPP_UNSET was only introduced in OpenFlow 1.5.
1750 Values that will never appear when receiving a packet may still be
1752 matched against in the flow table. There are still circumstances in
1753 which those flows can be matched:
1754 · The resubmit Open vSwitch extension action allows a flow
1756 table lookup with an arbitrary ingress port.
1757 · An action that modifies the ingress port field (see
1759 below), such as e.g. load or set_field, followed by an
1760 action or instruction that performs another flow table
1761 lookup, such as resubmit or goto_table.
1762 This field is heavily used for matching in OpenFlow tables, but for
1764 packet egress, it has only very limited roles:
1765 · OpenFlow requires suppressing output actions to in_port.
1767 That is, the following two flows both drop all packets
1768 that arrive on port 1:
1769 in_port=1,actions=1
1771 in_port=1,actions=drop
1772 (This behavior is occasionally useful for flooding to a
1775 subset of ports. Specifying actions=1,2,3,4, for example,
1776 outputs to ports 1, 2, 3, and 4, omitting the ingress
1777 port.)
1778 · OpenFlow has a special port OFPP_IN_PORT (with value
1780 0xfff8) that outputs to the ingress port. For example, in
1781 a switch that has four ports numbered 1 through 4,
1782 actions=1,2,3,4,in_port outputs to ports 1, 2, 3, and 4,
1783 including the ingress port.
1784 Because the ingress port field has so little influence on packet pro‐
1786 cessing, it does not ordinarily make sense to modify the ingress port
1787 field. The field is writable only to support the occasional use case
1788 where the ingress port’s roles in packet egress, described above,
1789 become troublesome. For example, actions=load:0->NXM_OF_IN_PORT[],out‐
1790 put:123 will output to port 123 regardless of whether it is in the
1791 ingress port. If the ingress port is important, then one may save and
1792 restore it on the stack:
1793 actions=push:NXM_OF_IN_PORT[],load:0->NXM_OF_IN_PORT[],output:123,pop:NXM_OF_IN_PORT[]
1795 or, in Open vSwitch 2.7 or later, use the clone action to save and
1798 restore it:
1799 actions=clone(load:0->NXM_OF_IN_PORT[],output:123)
1801 The ability to modify the ingress port is an Open vSwitch extension to
1804 OpenFlow.
1805 OXM Ingress Port Field
1807 Name: in_port_oxm
1809 Width: 32 bits
1810 Format: OpenFlow 1.1+ port
1811 Masking: not maskable
1813 Prerequisites: none
1814 Access: read/write
1815 OpenFlow 1.0: not supported
1816 OpenFlow 1.1: yes (exact match only)
1817 OXM: OXM_OF_IN_PORT (0) since OpenFlow 1.2 and Open vSwitch
1818 1.7
1819 NXM: none
1820 OpenFlow 1.1 and later use a 32-bit port number, so this field supplies
1822 a 32-bit view of the ingress port. Current versions of Open vSwitch
1823 support only a 16-bit range of ports:
1824 · OpenFlow 1.0 ports 0x0000 to 0xfeff, inclusive, map to
1826 OpenFlow 1.1 port numbers with the same values.
1827 · OpenFlow 1.0 ports 0xff00 to 0xffff, inclusive, map to
1829 OpenFlow 1.1 port numbers 0xffffff00 to 0xffffffff.
1830 · OpenFlow 1.1 ports 0x0000ff00 to 0xfffffeff are not
1832 mapped and not supported.
1833 in_port and in_port_oxm are two views of the same information, so all
1835 of the comments on in_port apply to in_port_oxm too. Modifying in_port
1836 changes in_port_oxm, and vice versa.
1837 Setting in_port_oxm to an unsupported value yields unspecified behav‐
1839 ior.
1840 Output Queue Field
1842 Name: skb_priority
1844 Width: 32 bits
1845 Format: hexadecimal
1846 Masking: not maskable
1847 Prerequisites: none
1848 Access: read-only
1849 OpenFlow 1.0: not supported
1850 OpenFlow 1.1: not supported
1852 OXM: none
1853 NXM: none
1854 Future Directions: Open vSwitch implements the output queue as a field,
1856 but does not currently expose it through OXM or NXM for matching pur‐
1857 poses. If this turns out to be a useful feature, it could be imple‐
1858 mented in future versions. Only the set_queue, enqueue, and pop_queue
1859 actions currently influence the output queue.
1860 This field influences how packets in the flow will be queued, for qual‐
1862 ity of service (QoS) purposes, when they egress the switch. Its range
1863 of meaningful values, and their meanings, varies greatly from one Open‐
1864 Flow implementation to another. Even within a single implementation,
1865 there is no guarantee that all OpenFlow ports have the same queues con‐
1866 figured or that all OpenFlow ports in an implementation can be config‐
1867 ured the same way queue-wise.
1868 Configuring queues on OpenFlow is not well standardized. On Linux, Open
1870 vSwitch supports queue configuration via OVSDB, specifically the QoS
1871 and Queue tables (see ovs-vswitchd.conf.db(5) for details). Ports of
1872 Open vSwitch to other platforms might require queue configuration
1873 through some separate protocol (such as a CLI). Even on Linux, Open
1874 vSwitch exposes only a fraction of the kernel’s queuing features
1875 through OVSDB, so advanced or unusual uses might require use of sepa‐
1876 rate utilities (e.g. tc). OpenFlow switches other than Open vSwitch
1877 might use OF-CONFIG or any of the configuration methods mentioned
1878 above. Finally, some OpenFlow switches have a fixed number of fixed-
1879 function queues (e.g. eight queues with strictly defined priorities)
1880 and others do not support any control over queuing.
1881 The only output queue that all OpenFlow implementations must support is
1883 zero, to identify a default queue, whose properties are implementation-
1884 defined. Outputting a packet to a queue that does not exist on the out‐
1885 put port yields unpredictable behavior: among the possibilities are
1886 that the packet might be dropped or transmitted with a very high or
1887 very low priority.
1888 OpenFlow 1.0 only allowed output queues to be specified as part of an
1890 enqueue action that specified both a queue and an output port. That is,
1891 OpenFlow 1.0 treats the queue as an argument to an action, not as a
1892 field.
1893 To increase flexibility, OpenFlow 1.1 added an action to set the output
1895 queue. This model was carried forward, without change, through OpenFlow
1896 1.5.
1897 Open vSwitch implements the native queuing model of each OpenFlow ver‐
1899 sion it supports. Open vSwitch also includes an extension for setting
1900 the output queue as an action in OpenFlow 1.0.
1901 When a packet ingresses into an OpenFlow switch, the output queue is
1903 ordinarily set to 0, indicating the default queue. However, Open
1904 vSwitch supports various ways to forward a packet from one OpenFlow
1905 switch to another within a single host. In these cases, Open vSwitch
1906 maintains the output queue across the forwarding step. For example:
1907 · A hop across an Open vSwitch ``patch port’’ (which does
1909 not actually involve queuing) preserves the output queue.
1910 · When a flow sets the output queue then outputs to an
1912 OpenFlow tunnel port, the encapsulation preserves the
1913 output queue. If the kernel TCP/IP stack routes the
1914 encapsulated packet directly to a physical interface,
1915 then that output honors the output queue. Alternatively,
1916 if the kernel routes the encapsulated packet to another
1917 Open vSwitch bridge, then the output queue set previously
1918 becomes the initial output queue on ingress to the second
1919 bridge and will thus be used for further output actions
1920 (unless overridden by a new ``set queue’’ action).
1921 (This description reflects the current behavior of Open
1923 vSwitch on Linux. This behavior relies on details of the
1924 Linux TCP/IP stack. It could be difficult to make ports
1925 to other operating systems behave the same way.)
1926 Packet Mark Field
1928 Name: pkt_mark
1930 Width: 32 bits
1931 Format: hexadecimal
1932 Masking: arbitrary bitwise masks
1933 Prerequisites: none
1934 Access: read/write
1935 OpenFlow 1.0: not supported
1936 OpenFlow 1.1: not supported
1937 OXM: none
1938 NXM: NXM_NX_PKT_MARK (33) since Open vSwitch 2.0
1939 Packet mark comes to Open vSwitch from the Linux kernel, in which the
1941 sk_buff data structure that represents a packet contains a 32-bit mem‐
1942 ber named skb_mark. The value of skb_mark propagates along with the
1943 packet it accompanies wherever the packet goes in the kernel. It has no
1944 predefined semantics but various kernel-user interfaces can set and
1945 match on it, which makes it suitable for ``marking’’ packets at one
1946 point in their handling and then acting on the mark later. With ipta‐
1947 bles, for example, one can mark some traffic specially at ingress and
1948 then handle that traffic differently at egress based on the marked
1949 value.
1950 Packet mark is an attempt at a generalization of the skb_mark concept
1952 beyond Linux, at least through more generic naming. Like skb_priority,
1953 packet mark is preserved across forwarding steps within a machine.
1954 Unlike skb_priority, packet mark has no direct effect on packet for‐
1955 warding: the value set in packet mark does not matter unless some later
1956 OpenFlow table or switch matches on packet mark, or unless the packet
1957 passes through some other kernel subsystem that has been configured to
1958 interpret packet mark in specific ways, e.g. through iptables configu‐
1959 ration mentioned above.
1960 Preserving packet mark across kernel forwarding steps relies heavily on
1962 kernel support, which ports to non-Linux operating systems may not
1963 have. Regardless of operating system support, Open vSwitch supports
1964 packet mark within a single bridge and across patch ports.
1965 The value of packet mark when a packet ingresses into the first Open
1967 vSwich bridge is typically zero, but it could be nonzero if its value
1968 was previously set by some kernel subsystem.
1969 Action Set Output Port Field
1971 Name: actset_output
1973 Width: 32 bits
1974 Format: OpenFlow 1.1+ port
1975 Masking: not maskable
1976 Prerequisites: none
1977 Access: read-only
1978 OpenFlow 1.0: not supported
1979 OpenFlow 1.1: not supported
1980 OXM: ONFOXM_ET_ACTSET_OUTPUT (43) since OpenFlow 1.3 and
1982 Open vSwitch 2.4; OXM_OF_ACTSET_OUTPUT [22m(43) since
1983 OpenFlow 1.5 and Open vSwitch 2.4
1984 NXM: none
1985 Holds the output port currently in the OpenFlow action set (i.e. from
1987 an output action within a write_actions instruction). Its value is an
1988 OpenFlow port number. If there is no output port in the OpenFlow action
1989 set, or if the output port will be ignored (e.g. because there is an
1990 output group in the OpenFlow action set), then the value will be
1991 OFPP_UNSET.
1992 Open vSwitch allows any table to match this field. OpenFlow, however,
1994 only requires this field to be matchable from within an OpenFlow egress
1995 table (a feature that Open vSwitch does not yet implement).
1996 Packet Type Field
1998 Name: packet_type
2000 Width: 32 bits
2001 Format: packet type
2002 Masking: not maskable
2003 Prerequisites: none
2004 Access: read-only
2005 OpenFlow 1.0: not supported
2006 OpenFlow 1.1: not supported
2008 OXM: OXM_OF_PACKET_TYPE [22m(44) since OpenFlow 1.5 and Open
2009 vSwitch 2.8
2010 NXM: none
2011 The type of the packet in the format specified in OpenFlow 1.5:
2013 Packet type
2015 <--------->
2016 16 16
2017 +---+-------+
2018 |ns |ns_type| ...
2019 +---+-------+
2020 The upper 16 bits, ns, are a namespace. The meaning of ns_type depends
2023 on the namespace. The packet type field is specified and displayed in
2024 the format (ns,ns_type).
2025 Open vSwitch currently supports the following classes of packet types
2027 for matching:
2028 (0,0) Ethernet.
2030 (1,ethertype)
2032 The specified ethertype. Open vSwitch can forward packets
2033 with any ethertype, but it can only match on and process
2034 data fields for the following supported packet types:
2035 (1,0x800)
2037 IPv4
2038 (1,0x806)
2040 ARP
2041 (1,0x86dd)
2043 IPv6
2044 (1,0x8847)
2046 MPLS
2047 (1,0x8848)
2049 MPLS multicast
2050 (1,0x8035)
2052 RARP
2053 (1,0x894f)
2055 NSH
2056 Consider the distinction between a packet with packet_type=(0,0),
2058 dl_type=0x800 and one with packet_type=(1,0x800). The former is an Eth‐
2059 ernet frame that contains an IPv4 packet, like this:
2060 Ethernet IPv4
2062 <-----------> <--------------->
2063 48 48 16 8 32 32
2064 +---+---+-----+ +---+-----+---+---+
2065 |dst|src|type | |...|proto|src|dst| ...
2066 +---+---+-----+ +---+-----+---+---+
2067 0x800
2068 The latter is an IPv4 packet not encapsulated inside any outer frame,
2071 like this:
2072 IPv4
2074 <--------------->
2075 8 32 32
2076 +---+-----+---+---+
2077 |...|proto|src|dst| ...
2078 +---+-----+---+---+
2079 Matching on packet_type is a pre-requisite for matching on any data
2082 field, but for backward compatibility, when a match on a data field is
2083 present without a packet_type match, Open vSwitch acts as though a
2084 match on (0,0) (Ethernet) had been supplied. Similarly, when Open
2085 vSwitch sends flow match information to a controller, e.g. in a reply
2086 to a request to dump the flow table, Open vSwitch omits a match on
2087 packet type (0,0) if it would be implied by a data field match.
2088
2090 Summary:
2091 Name Bytes Mask RW? Prereqs NXM/OXM Support
2092 ──────────── ────── ───── ──── ──────── ────────────────
2093 ct_state 4 yes no none OVS 2.5+
2094 ct_zone 2 no no none OVS 2.5+
2095 ct_mark 4 yes yes none OVS 2.5+
2096 ct_label 16 yes yes none OVS 2.5+
2097 ct_nw_src 4 yes no CT OVS 2.8+
2098 ct_nw_dst 4 yes no CT OVS 2.8+
2099 ct_ipv6_src 16 yes no CT OVS 2.8+
2101 ct_ipv6_dst 16 yes no CT OVS 2.8+
2102 ct_nw_proto 1 no no CT OVS 2.8+
2103 ct_tp_src 2 yes no CT OVS 2.8+
2104 ct_tp_dst 2 yes no CT OVS 2.8+
2105 Open vSwitch 2.5 and later support ``connection tracking,’’ which
2107 allows bidirectional streams of packets to be statefully grouped into
2108 connections. Open vSwitch connection tracking, for example, identifies
2109 the patterns of TCP packets that indicates a successfully initiated
2110 connection, as well as those that indicate that a connection has been
2111 torn down. Open vSwitch connection tracking can also identify related
2112 connections, such as FTP data connections spawned from FTP control con‐
2113 nections.
2114 An individual packet passing through the pipeline may be in one of two
2116 states, ``untracked’’ or ``tracked,’’ which may be distinguished via
2117 the ``trk’’ flag in ct_state. A packet is untracked at the beginning of
2118 the Open vSwitch pipeline and continues to be untracked until the pipe‐
2119 line invokes the ct action. The connection tracking fields are all
2120 zeroes in an untracked packet. When a flow in the Open vSwitch pipeline
2121 invokes the ct action, the action initializes the connection tracking
2122 fields and the packet becomes tracked for the remainder of its process‐
2123 ing.
2124 The connection tracker stores connection state in an internal table,
2126 but it only adds a new entry to this table when a ct action for a new
2127 connection invokes ct with the commit parameter. For a given connec‐
2128 tion, when a pipeline has executed ct, but not yet with commit, the
2129 connection is said to be uncommitted. State for an uncommitted connec‐
2130 tion is ephemeral and does not persist past the end of the pipeline, so
2131 some features are only available to committed connections. A connection
2132 would typically be left uncommitted as a way to drop its packets.
2133 Connection tracking is an Open vSwitch extension to OpenFlow.
2135 Connection Tracking State Field
2137 Name: ct_state
2139 Width: 32 bits
2140 Format: ct state
2141 Masking: arbitrary bitwise masks
2142 Prerequisites: none
2143 Access: read-only
2144 OpenFlow 1.0: not supported
2145 OpenFlow 1.1: not supported
2146 OXM: none
2147 NXM: NXM_NX_CT_STATE (105) since Open vSwitch 2.5
2149 This field holds several flags that can be used to determine the state
2151 of the connection to which the packet belongs.
2152 Matches on this field are most conveniently written in terms of sym‐
2154 bolic names (listed below), each preceded by either + for a flag that
2155 must be set, or - for a flag that must be unset, without any other
2156 delimiters between the flags. Flags not mentioned are wildcarded. For
2157 example, tcp,ct_state=+trk-new matches TCP packets that have been run
2158 through the connection tracker and do not establish a new connection.
2159 Matches can also be written as flags/mask, where flags and mask are
2160 32-bit numbers in decimal or in hexadecimal prefixed by 0x.
2161 The following flags are defined:
2163 new (0x01)
2165 A new connection. Set to 1 if this is an uncommitted con‐
2166 nection.
2167 est (0x02)
2169 Part of an existing connection. Set to 1 if this is a
2170 committed connection.
2171 rel (0x04)
2173 Related to an existing connection, e.g. an ICMP ``desti‐
2174 nation unreachable’’ message or an FTP data connections.
2175 This flag will only be 1 if the connection to which this
2176 one is related is committed.
2177 Connections identified as rel are separate from the orig‐
2179 inating connection and must be committed separately. All
2180 packets for a related connection will have the rel flag
2181 set, not just the initial packet.
2182 rpl (0x08)
2184 This packet is in the reply direction, meaning that it is
2185 in the opposite direction from the packet that initiated
2186 the connection. This flag will only be 1 if the connec‐
2187 tion is committed.
2188 inv (0x10)
2190 The state is invalid, meaning that the connection tracker
2191 couldn’t identify the connection. This flag is a catch-
2192 all for problems in the connection or the connection
2193 tracker, such as:
2194 · L3/L4 protocol handler is not loaded/unavailable.
2196 With the Linux kernel datapath, this may mean that
2197 the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules
2198 are not loaded.
2199 · L3/L4 protocol handler determines that the packet
2201 is malformed.
2202 · Packets are unexpected length for protocol.
2204 trk (0x20)
2206 This packet is tracked, meaning that it has previously
2207 traversed the connection tracker. If this flag is not
2208 set, then no other flags will be set. If this flag is
2209 set, then the packet is tracked and other flags may also
2210 be set.
2211 snat (0x40)
2213 This packet was transformed by source address/port trans‐
2214 lation by a preceding ct action. Open vSwitch 2.6 added
2215 this flag.
2216 dnat (0x80)
2218 This packet was transformed by destination address/port
2219 translation by a preceding ct action. Open vSwitch 2.6
2220 added this flag.
2221 There are additional constraints on these flags, listed in decreasing
2223 order of precedence below:
2224 1. If trk is unset, no other flags are set.
2226 2. If trk is set, one or more other flags may be set.
2228 3. If inv is set, only the trk flag is also set.
2230 4. new and est are mutually exclusive.
2232 5. new and rpl are mutually exclusive.
2234 6. rel may be set in conjunction with any other flags.
2236 Future versions of Open vSwitch may define new flags.
2238 Connection Tracking Zone Field
2240 Name: ct_zone
2242 Width: 16 bits
2243 Format: hexadecimal
2244 Masking: not maskable
2245 Prerequisites: none
2246 Access: read-only
2248 OpenFlow 1.0: not supported
2249 OpenFlow 1.1: not supported
2250 OXM: none
2251 NXM: NXM_NX_CT_ZONE (106) since Open vSwitch 2.5
2252 A connection tracking zone, the zone value passed to the most recent ct
2254 action. Each zone is an independent connection tracking context, so
2255 tracking the same packet in multiple contexts requires using the ct
2256 action multiple times.
2257 Connection Tracking Mark Field
2259 Name: ct_mark
2261 Width: 32 bits
2262 Format: hexadecimal
2264 Masking: arbitrary bitwise masks
2265 Prerequisites: none
2266 Access: read/write
2267 OpenFlow 1.0: not supported
2268 OpenFlow 1.1: not supported
2269 OXM: none
2270 NXM: NXM_NX_CT_MARK (107) since Open vSwitch 2.5
2271 The metadata committed, by an action within the exec parameter to the
2273 ct action, to the connection to which the current packet belongs.
2274 Connection Tracking Label Field
2276 Name: ct_label
2278 Width: 128 bits
2280 Format: hexadecimal
2281 Masking: arbitrary bitwise masks
2282 Prerequisites: none
2283 Access: read/write
2284 OpenFlow 1.0: not supported
2285 OpenFlow 1.1: not supported
2286 OXM: none
2287 NXM: NXM_NX_CT_LABEL (108) since Open vSwitch 2.5
2288 The label committed, by an action within the exec parameter to the ct
2290 action, to the connection to which the current packet belongs.
2291 Open vSwitch 2.8 introduced the matching support for connection tracker
2293 original direction 5-tuple fields.
2294 For non-committed non-related connections the conntrack original direc‐
2296 tion tuple fields always have the same values as the corresponding
2297 headers in the packet itself. For any other packets of a committed con‐
2298 nection the conntrack original direction tuple fields reflect the val‐
2299 ues from that initial non-committed non-related packet, and thus may be
2300 different from the actual packet headers, as the actual packet headers
2301 may be in reverse direction (for reply packets), transformed by NAT
2302 (when nat option was applied to the connection), or be of different
2303 protocol (i.e., when an ICMP response is sent to an UDP packet). In
2304 case of related connections, e.g., an FTP data connection, the original
2305 direction tuple contains the original direction headers from the master
2306 connection, e.g., an FTP control connection.
2307 The following fields are populated by the ct action, and require a
2309 match to a valid connection tracking state as a prerequisite, in addi‐
2310 tion to the IP or IPv6 ethertype match. Examples of valid connection
2311 tracking state matches include ct_state=+new, ct_state=+est,
2312 ct_state=+rel, and ct_state=+trk-inv.
2313 Connection Tracking Original Direction IPv4 Source Address Field
2315 Name: ct_nw_src
2317 Width: 32 bits
2318 Format: IPv4
2319 Masking: arbitrary bitwise masks
2320 Prerequisites: CT
2321 Access: read-only
2322 OpenFlow 1.0: not supported
2323 OpenFlow 1.1: not supported
2324 OXM: none
2325 NXM: NXM_NX_CT_NW_SRC (120) since Open vSwitch 2.8
2326 Matches IPv4 conntrack original direction tuple source address. See the
2328 paragraphs above for general description to the conntrack original
2329 direction tuple. Introduced in Open vSwitch 2.8.
2330 Connection Tracking Original Direction IPv4 Destination Address Field
2332 Name: ct_nw_dst
2334 Width: 32 bits
2335 Format: IPv4
2336 Masking: arbitrary bitwise masks
2337 Prerequisites: CT
2338 Access: read-only
2339 OpenFlow 1.0: not supported
2340 OpenFlow 1.1: not supported
2341 OXM: none
2342 NXM: NXM_NX_CT_NW_DST (121) since Open vSwitch 2.8
2344 Matches IPv4 conntrack original direction tuple destination address.
2346 See the paragraphs above for general description to the conntrack orig‐
2347 inal direction tuple. Introduced in Open vSwitch 2.8.
2348 Connection Tracking Original Direction IPv6 Source Address Field
2350 Name: ct_ipv6_src
2352 Width: 128 bits
2353 Format: IPv6
2354 Masking: arbitrary bitwise masks
2355 Prerequisites: CT
2356 Access: read-only
2357 OpenFlow 1.0: not supported
2358 OpenFlow 1.1: not supported
2360 OXM: none
2361 NXM: NXM_NX_CT_IPV6_SRC (122) since Open vSwitch 2.8
2362 Matches IPv6 conntrack original direction tuple source address. See the
2364 paragraphs above for general description to the conntrack original
2365 direction tuple. Introduced in Open vSwitch 2.8.
2366 Connection Tracking Original Direction IPv6 Destination Address Field
2368 Name: ct_ipv6_dst
2370 Width: 128 bits
2371 Format: IPv6
2372 Masking: arbitrary bitwise masks
2373 Prerequisites: CT
2374 Access: read-only
2376 OpenFlow 1.0: not supported
2377 OpenFlow 1.1: not supported
2378 OXM: none
2379 NXM: NXM_NX_CT_IPV6_DST (123) since Open vSwitch 2.8
2380 Matches IPv6 conntrack original direction tuple destination address.
2382 See the paragraphs above for general description to the conntrack orig‐
2383 inal direction tuple. Introduced in Open vSwitch 2.8.
2384 Connection Tracking Original Direction IP Protocol Field
2386 Name: ct_nw_proto
2388 Width: 8 bits
2389 Format: decimal
2390 Masking: not maskable
2392 Prerequisites: CT
2393 Access: read-only
2394 OpenFlow 1.0: not supported
2395 OpenFlow 1.1: not supported
2396 OXM: none
2397 NXM: NXM_NX_CT_NW_PROTO (119) since Open vSwitch 2.8
2398 Matches conntrack original direction tuple IP protocol type, which is
2400 specified as a decimal number between 0 and 255, inclusive (e.g. 1 to
2401 match ICMP packets or 6 to match TCP packets). In case of, for example,
2402 an ICMP response to an UDP packet, this may be different from the IP
2403 protocol type of the packet itself. See the paragraphs above for gen‐
2404 eral description to the conntrack original direction tuple. Introduced
2405 in Open vSwitch 2.8.
2406 Connection Tracking Original Direction Transport Layer Source Port
2408 Field
2409 Name: ct_tp_src
2411 Width: 16 bits
2412 Format: decimal
2413 Masking: arbitrary bitwise masks
2414 Prerequisites: CT
2415 Access: read-only
2416 OpenFlow 1.0: not supported
2417 OpenFlow 1.1: not supported
2418 OXM: none
2419 NXM: NXM_NX_CT_TP_SRC (124) since Open vSwitch 2.8
2420 Bitwise match on the conntrack original direction tuple transport
2422 source, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or 132
2423 for SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58 for ICMPv6,
2424 the lower 8 bits of MFF_CT_TP_SRC matches the conntrack original direc‐
2425 tion ICMP type. See the paragraphs above for general description to the
2426 conntrack original direction tuple. Introduced in Open vSwitch 2.8.
2427 Connection Tracking Original Direction Transport Layer Source Port
2429 Field
2430 Name: ct_tp_dst
2432 Width: 16 bits
2433 Format: decimal
2434 Masking: arbitrary bitwise masks
2435 Prerequisites: CT
2436 Access: read-only
2437 OpenFlow 1.0: not supported
2438 OpenFlow 1.1: not supported
2440 OXM: none
2441 NXM: NXM_NX_CT_TP_DST (125) since Open vSwitch 2.8
2442 Bitwise match on the conntrack original direction tuple transport des‐
2444 tination port, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or
2445 132 for SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58 for
2446 ICMPv6, the lower 8 bits of MFF_CT_TP_DST matches the conntrack origi‐
2447 nal direction ICMP code. See the paragraphs above for general descrip‐
2448 tion to the conntrack original direction tuple. Introduced in Open
2449 vSwitch 2.8.
2450
2452 Summary:
2453 Name Bytes Mask RW? Prereqs NXM/OXM Support
2454 ───────── ────── ───── ──── ──────── ─────────────────────
2455 metadata 8 yes yes none OF 1.2+ and OVS 1.8+
2456 reg0 4 yes yes none OVS 1.1+
2457 reg1 4 yes yes none OVS 1.1+
2458 reg2 4 yes yes none OVS 1.1+
2459 reg3 4 yes yes none OVS 1.1+
2460 reg4 4 yes yes none OVS 1.3+
2462 reg5 4 yes yes none OVS 1.7+
2463 reg6 4 yes yes none OVS 1.7+
2464 reg7 4 yes yes none OVS 1.7+
2465 reg8 4 yes yes none OVS 2.6+
2466 reg9 4 yes yes none OVS 2.6+
2467 reg10 4 yes yes none OVS 2.6+
2468 reg11 4 yes yes none OVS 2.6+
2469 reg12 4 yes yes none OVS 2.6+
2470 reg13 4 yes yes none OVS 2.6+
2471 reg14 4 yes yes none OVS 2.6+
2473 reg15 4 yes yes none OVS 2.6+
2474 xreg0 8 yes yes none OF 1.3+ and OVS 2.4+
2475 xreg1 8 yes yes none OF 1.3+ and OVS 2.4+
2476 xreg2 8 yes yes none OF 1.3+ and OVS 2.4+
2477 xreg3 8 yes yes none OF 1.3+ and OVS 2.4+
2478 xreg4 8 yes yes none OF 1.3+ and OVS 2.4+
2479 xreg5 8 yes yes none OF 1.3+ and OVS 2.4+
2480 xreg6 8 yes yes none OF 1.3+ and OVS 2.4+
2481 xreg7 8 yes yes none OF 1.3+ and OVS 2.4+
2482 xxreg0 16 yes yes none OVS 2.6+
2484 xxreg1 16 yes yes none OVS 2.6+
2485 xxreg2 16 yes yes none OVS 2.6+
2486 xxreg3 16 yes yes none OVS 2.6+
2487 These fields give an OpenFlow switch space for temporary storage while
2489 the pipeline is running. Whereas metadata fields can have a meaningful
2490 initial value and can persist across some hops across OpenFlow
2491 switches, registers are always initially 0 and their values never per‐
2492 sist across inter-switch hops (not even across patch ports).
2493 OpenFlow Metadata Field
2495 Name: metadata
2497 Width: 64 bits
2498 Format: hexadecimal
2499 Masking: arbitrary bitwise masks
2500 Prerequisites: none
2501 Access: read/write
2502 OpenFlow 1.0: not supported
2503 OpenFlow 1.1: yes
2504 OXM: OXM_OF_METADATA [22m(2) since OpenFlow 1.2 and Open
2506 vSwitch 1.8
2507 NXM: none
2508 This field is the oldest standardized OpenFlow register field, intro‐
2510 duced in OpenFlow 1.1. It was introduced to model the limited number of
2511 user-defined bits that some ASIC-based switches can carry through their
2512 pipelines. Because of hardware limitations, OpenFlow allows switches to
2513 support writing and masking only an implementation-defined subset of
2514 bits, even no bits at all. The Open vSwitch software switch always sup‐
2515 ports all 64 bits, but of course an Open vSwitch port to an ASIC would
2516 have the same restriction as the ASIC itself.
2517 This field has an OXM code point, but OpenFlow 1.4 and earlier allow it
2519 to be modified only with a specialized instruction, not with a ``set-
2520 field’’ action. OpenFlow 1.5 removes this restriction. Open vSwitch
2521 does not enforce this restriction, regardless of OpenFlow version.
2522 Register 0 Field
2524 Name: reg0
2526 Width: 32 bits
2528 Format: hexadecimal
2529 Masking: arbitrary bitwise masks
2530 Prerequisites: none
2531 Access: read/write
2532 OpenFlow 1.0: not supported
2533 OpenFlow 1.1: not supported
2534 OXM: none
2535 NXM: NXM_NX_REG0 (0) since Open vSwitch 1.1
2536 This is the first of several Open vSwitch registers, all of which have
2538 the same properties. Open vSwitch 1.1 introduced registers 0, 1, 2, and
2539 3, version 1.3 added register 4, version 1.7 added registers 5, 6, and
2540 7, and version 2.6 added registers 8 through 15.
2541 Extended Register 0 Field
2543 Name: xreg0
2545 Width: 64 bits
2546 Format: hexadecimal
2547 Masking: arbitrary bitwise masks
2548 Prerequisites: none
2550 Access: read/write
2551 OpenFlow 1.0: not supported
2552 OpenFlow 1.1: not supported
2553 OXM: OXM_OF_PKT_REG0 [22m(0) since OpenFlow 1.3 and Open
2554 vSwitch 2.4
2555 NXM: none
2556 This is the first of the registers introduced in OpenFlow 1.5. OpenFlow
2558 1.5 calls these fields just the ``packet registers,’’ but Open vSwitch
2559 already had 32-bit registers by that name, so Open vSwitch uses the
2560 name ``extended registers’’ in an attempt to reduce confusion. The
2561 standard allows for up to 128 registers, each 64 bits wide, but Open
2562 vSwitch only implements 4 (in versions 2.4 and 2.5) or 8 (in version
2563 2.6 and later).
2564 Each of the 64-bit extended registers overlays two of the 32-bit regis‐
2566 ters: xreg0 overlays reg0 and reg1, with reg0 supplying the most-sig‐
2567 nificant bits of xreg0 and reg1 the least-significant. Similarly, xreg1
2568 overlays reg2 and reg3, and so on.
2569 The OpenFlow specification says, ``In most cases, the packet registers
2571 can not be matched in tables, i.e. they usually can not be used in the
2572 flow entry match structure’’ [OpenFlow 1.5, section 7.2.3.10], but
2573 there is no reason for a software switch to impose such a restriction,
2574 and Open vSwitch does not.
2575 Double-Extended Register 0 Field
2577 Name: xxreg0
2579 Width: 128 bits
2580 Format: hexadecimal
2581 Masking: arbitrary bitwise masks
2583 Prerequisites: none
2584 Access: read/write
2585 OpenFlow 1.0: not supported
2586 OpenFlow 1.1: not supported
2587 OXM: none
2588 NXM: NXM_NX_XXREG0 (111) since Open vSwitch 2.6
2589 This is the first of the double-extended registers introduce in Open
2591 vSwitch 2.6. Each of the 128-bit extended registers overlays four of
2592 the 32-bit registers: xxreg0 overlays reg0 through reg3, with reg0 sup‐
2593 plying the most-significant bits of xxreg0 and reg3 the least-signifi‐
2594 cant. xxreg1 similarly overlays reg4 through reg7, and so on.
2595
2597 Summary:
2598 Name Bytes Mask RW? Prereqs NXM/OXM Support
2599 ───────────────────── ────── ───── ──── ───────── ─────────────────────
2601 eth_src aka dl_src 6 yes yes Ethernet OF 1.2+ and OVS 1.1+
2602 eth_dst aka dl_dst 6 yes yes Ethernet OF 1.2+ and OVS 1.1+
2603 eth_type aka dl_type 2 no no Ethernet OF 1.2+ and OVS 1.1+
2604 Ethernet is the only layer-2 protocol that Open vSwitch supports. As
2606 with most software, Open vSwitch and OpenFlow regard an Ethernet frame
2607 to begin with the 14-byte header and end with the final byte of the
2608 payload; that is, the frame check sequence is not considered part of
2609 the frame.
2610 Ethernet Source Field
2612 Name: eth_src (aka dl_src)
2614 Width: 48 bits
2616 Format: Ethernet
2617 Masking: arbitrary bitwise masks
2618 Prerequisites: Ethernet
2619 Access: read/write
2621 OpenFlow 1.0: yes (exact match only)
2622 OpenFlow 1.1: yes
2623 OXM: OXM_OF_ETH_SRC (4) since OpenFlow 1.2 and Open vSwitch
2626 1.7
2627 NXM: NXM_OF_ETH_SRC (2) since Open vSwitch 1.1
2628 The Ethernet source address:
2630 Ethernet
2632 <---------->
2633 48 48 16
2634 +---+---+----+
2635 |dst|src|type| ...
2636 +---+---+----+
2637 Ethernet Destination Field
2640 Name: eth_dst (aka dl_dst)
2642 Width: 48 bits
2643 Format: Ethernet
2644 Masking: arbitrary bitwise masks
2646 Prerequisites: Ethernet
2647 Access: read/write
2648 OpenFlow 1.0: yes (exact match only)
2649 OpenFlow 1.1: yes
2651 OXM: OXM_OF_ETH_DST (3) since OpenFlow 1.2 and Open vSwitch
2652 1.7
2653 NXM: NXM_OF_ETH_DST (1) since Open vSwitch 1.1
2654 The Ethernet destination address:
2656 Ethernet
2658 <---------->
2659 48 48 16
2660 +---+---+----+
2661 |dst|src|type| ...
2662 +---+---+----+
2663 Open vSwitch 1.8 and later support arbitrary masks for source and/or
2666 destination. Earlier versions only support masking the destination with
2667 the following masks:
2668 01:00:00:00:00:00
2670 Match only the multicast bit. Thus,
2671 dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 matches all
2672 multicast (including broadcast) Ethernet packets, and
2673 dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 matches all
2674 unicast Ethernet packets.
2675 fe:ff:ff:ff:ff:ff
2677 Match all bits except the multicast bit. This is probably
2678 not useful.
2679 ff:ff:ff:ff:ff:ff
2681 Exact match (equivalent to omitting the mask).
2682 00:00:00:00:00:00
2684 Wildcard all bits (equivalent to dl_dst=*).
2685 Ethernet Type Field
2687 Name: eth_type (aka dl_type)
2689 Width: 16 bits
2690 Format: hexadecimal
2691 Masking: not maskable
2692 Prerequisites: Ethernet
2694 Access: read-only
2695 OpenFlow 1.0: yes (exact match only)
2696 OpenFlow 1.1: yes (exact match only)
2697 OXM: OXM_OF_ETH_TYPE [22m(5) since OpenFlow 1.2 and Open
2698 vSwitch 1.7
2699 NXM: NXM_OF_ETH_TYPE (3) since Open vSwitch 1.1
2701 The most commonly seen Ethernet frames today use a format called ``Eth‐
2703 ernet II,’’ in which the last two bytes of the Ethernet header specify
2704 the Ethertype. For such a frame, this field is copied from those bytes
2705 of the header, like so:
2706 Ethernet
2708 <---------------->
2709 48 48 16
2710 +---+---+----------+
2711 |dst|src| type | ...
2712 +---+---+----------+
2713 ≥0x600
2714 Every Ethernet type has a value 0x600 (1,536) or greater. When the last
2717 two bytes of the Ethernet header have a value too small to be an Ether‐
2718 net type, then the value found there is the total length of the frame
2719 in bytes, excluding the Ethernet header. An 802.2 LLC header typically
2720 follows the Ethernet header. OpenFlow and Open vSwitch only support LLC
2721 headers with DSAP and SSAP 0xaa and control byte 0x03, which indicate
2722 that a SNAP header follows the LLC header. In turn, OpenFlow and Open
2723 vSwitch only support a SNAP header with organization 0x000000. In such
2724 a case, this field is copied from the type field in the SNAP header,
2725 like this:
2726 Ethernet LLC SNAP
2728 <------------> <------------> <----------------->
2729 48 48 16 8 8 8 24 16
2730 +---+---+------+ +----+----+----+ +--------+----------+
2731 |dst|src| type | |DSAP|SSAP|cntl| | org | type | ...
2732 +---+---+------+ +----+----+----+ +--------+----------+
2733 <0x600 0xaa 0xaa 0x03 0x000000 ≥0x600
2734 When an 802.1Q header is inserted after the Ethernet source and desti‐
2737 nation, this field is populated with the encapsulated Ethertype, not
2738 the 802.1Q Ethertype. With an Ethernet II inner frame, the result looks
2739 like this:
2740 Ethernet 802.1Q Ethertype
2742 <------> <--------> <-------->
2743 48 48 16 16 16
2744 +----+---+ +------+---+ +----------+
2745 |dst |src| | TPID |TCI| | type | ...
2746 +----+---+ +------+---+ +----------+
2747 0x8100 ≥0x600
2748 LLC and SNAP encapsulation look like this with an 802.1Q header:
2751 Ethernet 802.1Q Ethertype LLC SNAP
2753 <------> <--------> <-------> <------------> <----------------->
2754 48 48 16 16 16 8 8 8 24 16
2755 +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2756 |dst |src| | TPID |TCI| | type | |DSAP|SSAP|cntl| | org | type | ...
2757 +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2758 0x8100 <0x600 0xaa 0xaa 0x03 0x000000 ≥0x600
2759 When a packet doesn’t match any of the header formats described above,
2762 Open vSwitch and OpenFlow set this field to 0x5ff
2763 (OFP_DL_TYPE_NOT_ETH_TYPE).
2764
2766 Summary:
2767 Name Bytes Mask RW? Prereqs NXM/OXM Support
2768 ──────────── ──────────────── ───── ──── ───────── ─────────────────────
2770 dl_vlan 2 (low 12 bits) no yes Ethernet
2771 dl_vlan_pcp 1 (low 3 bits) no yes Ethernet
2772 vlan_vid 2 (low 12 bits) yes yes Ethernet OF 1.2+ and OVS 1.7+
2774 vlan_pcp 1 (low 3 bits) no yes VLAN VID OF 1.2+ and OVS 1.7+
2775 vlan_tci 2 yes yes Ethernet OVS 1.1+
2776 The 802.1Q VLAN header causes more trouble than any other 4 bytes in
2778 networking. OpenFlow 1.0, 1.1, and 1.2+ all treat VLANs differently.
2779 Open vSwitch extensions add another variant to the mix. Open vSwitch
2780 reconciles all four treatments as best it can.
2781 VLAN Header Format
2783 An 802.1Q VLAN header consists of two 16-bit fields:
2784 TPID TCI
2786 <-------> <--------->
2787 16 3 1 12
2788 +---------+---+---+---+
2789 |Ethertype|PCP|CFI|VID|
2790 +---------+---+---+---+
2791 0x8100 0
2792 The first 16 bits of the VLAN header, the TPID (Tag Protocol IDenti‐
2795 fier), is an Ethertype. When the VLAN header is inserted just after the
2796 source and destination MAC addresses in a Ethertype frame, the TPID
2797 serves to identify the presence of the VLAN. The standard TPID, the
2798 only one that Open vSwitch supports, is 0x8100. OpenFlow 1.0 explicitly
2799 supports only TPID 0x8100. OpenFlow 1.1, but not earlier or later ver‐
2800 sions, also requires support for TPID 0x88a8 (Open vSwitch does not
2801 support this). OpenFlow 1.2 through 1.5 do not require support for spe‐
2802 cific TPIDs (the ``push vlan header’’ action does say that only 0x8100
2803 and 0x88a8 should be pushed). No version of OpenFlow provides a way to
2804 distinguish or match on the TPID.
2805 The remaining 16 bits of the VLAN header, the TCI (Tag Control Informa‐
2807 tion), is subdivided into three subfields:
2808 · PCP (Priority Control Point), is a 3-bit 802.1p priority.
2810 The lowest priority is value 1, the second-lowest is
2811 value 0, and priority increases from 2 up to highest pri‐
2812 ority 7.
2813 · CFI (Canonical Format Indicator), is a 1-bit field. On an
2815 Ethernet network, its value is always 0. This led to it
2816 later being repurposed under the name DEI (Drop Eligibil‐
2817 ity Indicator). By either name, OpenFlow and Open vSwitch
2818 don’t provide any way to match or set this bit.
2819 · VID (VLAN IDentifier), is a 12-bit VLAN. If the VID is 0,
2821 then the frame is not part of a VLAN. In that case, the
2822 VLAN header is called a priority tag because it is only
2823 meaningful for assigning the frame a priority. VID 0xfff
2824 (4,095) is reserved.
2825 See eth_type for illustrations of a complete Ethernet frame with 802.1Q
2827 tag included.
2828 Multiple VLANs
2830 Open vSwitch can match only a single VLAN header. If more than one VLAN
2831 header is present, then eth_type holds the TPID of the inner VLAN
2832 header. Open vSwitch stops parsing the packet after the inner TPID, so
2833 matching further into the packet (e.g. on the inner TCI or L3 fields)
2834 is not possible.
2835 OpenFlow only directly supports matching a single VLAN header. In Open‐
2837 Flow 1.1 or later, one OpenFlow table can match on the outermost VLAN
2838 header and pop it off, and a later OpenFlow table can match on the next
2839 outermost header. Open vSwitch does not support this.
2840 VLAN Field Details
2842 The four variants have three different levels of expressiveness: Open‐
2843 Flow 1.0 and 1.1 VLAN matching are less powerful than OpenFlow 1.2+
2844 VLAN matching, which is less powerful than Open vSwitch extension VLAN
2845 matching.
2846 OpenFlow 1.0 VLAN Fields
2848 OpenFlow 1.0 uses two fields, called dl_vlan and dl_vlan_pcp, each of
2849 which can be either exact-matched or wildcarded, to specify VLAN
2850 matches:
2851 · When both dl_vlan and dl_vlan_pcp are wildcarded, the
2853 flow matches packets without an 802.1Q header or with any
2854 802.1Q header.
2855 · The match dl_vlan=0xffff causes a flow to match only
2857 packets without an 802.1Q header. Such a flow should also
2858 wildcard dl_vlan_pcp, since a packet without an 802.1Q
2859 header does not have a PCP. OpenFlow does not specify
2860 what to do if a match on PCP is actually present, but
2861 Open vSwitch ignores it.
2862 · Otherwise, the flow matches only packets with an 802.1Q
2864 header. If dl_vlan is not wildcarded, then the flow only
2865 matches packets with the VLAN ID specified in dl_vlan’s
2866 low 12 bits. If dl_vlan_pcp is not wildcarded, then the
2867 flow only matches packets with the priority specified in
2868 dl_vlan_pcp’s low 3 bits.
2869 OpenFlow does not specify how to interpret the high 4
2871 bits of dl_vlan or the high 5 bits of dl_vlan_pcp. Open
2872 vSwitch ignores them.
2873 OpenFlow 1.1 VLAN Fields
2875 VLAN matching in OpenFlow 1.1 is similar to OpenFlow 1.0. The one
2876 refinement is that when dl_vlan matches on 0xfffe (OFVPID_ANY), the
2877 flow matches only packets with an 802.1Q header, with any VLAN ID. If
2878 dl_vlan_pcp is wildcarded, the flow matches any packet with an 802.1Q
2879 header, regardless of VLAN ID or priority. If dl_vlan_pcp is not wild‐
2880 carded, then the flow only matches packets with the priority specified
2881 in dl_vlan_pcp’s low 3 bits.
2882 OpenFlow 1.1 uses the name OFPVID_NONE, instead of OFP_VLAN_NONE, for a
2884 dl_vlan of 0xffff, but it has the same meaning.
2885 In OpenFlow 1.1, Open vSwitch reports error OFPBMC_BAD_VALUE for an
2887 attempt to match on dl_vlan between 4,096 and 0xfffd, inclusive, or
2888 dl_vlan_pcp greater than 7.
2889 OpenFlow 1.2 VLAN Fields
2891 OpenFlow 1.2+ VLAN ID Field
2892 Name: vlan_vid
2894 Width: 16 bits (only the least-significant 12 bits may be nonzero)
2895 Format: decimal
2896 Masking: arbitrary bitwise masks
2897 Prerequisites: Ethernet
2898 Access: read/write
2899 OpenFlow 1.0: yes (exact match only)
2901 OpenFlow 1.1: yes (exact match only)
2902 OXM: OXM_OF_VLAN_VID (6) since OpenFlow 1.2 and Open vSwitch 1.7
2903 NXM: none
2904 The OpenFlow standard describes this field as consisting of ``12+1’’
2906 bits. On ingress, its value is 0 if no 802.1Q header is present, and
2907 otherwise it holds the VLAN VID in its least significant 12 bits, with
2908 bit 12 (0x1000 aka OFPVID_PRESENT) also set to 1. The three most sig‐
2909 nificant bits are always zero:
2910 OXM_OF_VLAN_VID
2912 <------------->
2913 3 1 12
2914 +---+--+--------+
2915 | |P |VLAN ID |
2916 +---+--+--------+
2917 0
2918 As a consequence of this field’s format, one may use it to match the
2921 VLAN ID in all of the ways available with the OpenFlow 1.0 and 1.1 for‐
2922 mats, and a few new ways:
2923 Fully wildcarded
2925 Matches any packet, that is, one without an 802.1Q header
2926 or with an 802.1Q header with any TCI value.
2927 Value 0x0000 (OFPVID_NONE), mask 0xffff (or no mask)
2929 Matches only packets without an 802.1Q header.
2930 Value 0x1000, mask 0x1000
2932 Matches any packet with an 802.1Q header, regardless of
2933 VLAN ID.
2934 Value 0x1009, mask 0xffff (or no mask)
2936 Match only packets with an 802.1Q header with VLAN ID 9.
2937 Value 0x1001, mask 0x1001
2939 Matches only packets that have an 802.1Q header with an
2940 odd-numbered VLAN ID. (This is just an example; one can
2941 match on any desired VLAN ID bit pattern.)
2942 OpenFlow 1.2+ VLAN Priority Field
2944 Name: vlan_pcp
2946 Width: 8 bits (only the least-significant 3 bits may be nonzero)
2947 Format: decimal
2948 Masking: not maskable
2950 Prerequisites: VLAN VID
2951 Access: read/write
2952 OpenFlow 1.0: yes (exact match only)
2953 OpenFlow 1.1: yes (exact match only)
2954 OXM: OXM_OF_VLAN_PCP [22m(7) since OpenFlow 1.2 and Open vSwitch
2957 1.7
2958 NXM: none
2959 The 3 least significant bits may be used to match the PCP bits in an
2961 802.1Q header. Other bits are always zero:
2962 OXM_OF_VLAN_VID
2964 <------------->
2965 5 3
2966 +--------+------+
2967 | zero | PCP |
2968 +--------+------+
2969 0
2970 This field may only be used when vlan_vid is not wildcarded and does
2973 not exact match on 0 (which only matches when there is no 802.1Q
2974 header).
2975 See VLAN Comparison Chart, below, for some examples.
2977 Open vSwitch Extension VLAN Field
2979 The vlan_tci extension can describe more kinds of VLAN matches than the
2980 other variants. It is also simpler than the other variants.
2981 VLAN TCI Field
2983 Name: vlan_tci
2985 Width: 16 bits
2986 Format: hexadecimal
2987 Masking: arbitrary bitwise masks
2988 Prerequisites: Ethernet
2989 Access: read/write
2990 OpenFlow 1.0: yes (exact match only)
2992 OpenFlow 1.1: yes (exact match only)
2993 OXM: none
2994 NXM: NXM_OF_VLAN_TCI (4) since Open vSwitch 1.1
2995 For a packet without an 802.1Q header, this field is zero. For a packet
2997 with an 802.1Q header, this field is the TCI with the bit in CFI’s
2998 position (marked P for ``present’’ below) forced to 1. Thus, for a
2999 packet in VLAN 9 with priority 7, it has the value 0xf009:
3000 NXM_VLAN_TCI
3002 <---------->
3003 3 1 12
3004 +----+--+----+
3005 |PCP |P |VID |
3006 +----+--+----+
3007 7 1 9
3008 Usage examples:
3011 vlan_tci=0
3013 Match packets without an 802.1Q header.
3014 vlan_tci=0x1000/0x1000
3016 Match packets with an 802.1Q header, regardless of VLAN
3017 and priority values.
3018 vlan_tci=0xf123
3020 Match packets tagged with priority 7 in VLAN 0x123.
3021 vlan_tci=0x1123/0x1fff
3023 Match packets tagged with VLAN 0x123 (and any priority).
3024 vlan_tci=0x5000/0xf000
3026 Match packets tagged with priority 2 (in any VLAN).
3027 vlan_tci=0/0xfff
3029 Match packets with no 802.1Q header or tagged with VLAN 0
3030 (and any priority).
3031 vlan_tci=0x5000/0xe000
3033 Match packets with no 802.1Q header or tagged with prior‐
3034 ity 2 (in any VLAN).
3035 vlan_tci=0/0xefff
3037 Match packets with no 802.1Q header or tagged with VLAN 0
3038 and priority 0.
3039 See VLAN Comparison Chart, below, for more examples.
3041 VLAN Comparison Chart
3043 The following table describes each of several possible matching crite‐
3044 ria on 802.1Q header may be expressed with each variation of the VLAN
3045 matching fields:
3046 Criteria OpenFlow 1.0 OpenFlow 1.1 OpenFlow 1.2+ NXM
3048 _ _ _ _ _
3049 [1] ????/1,??/? ????/1,??/? 0000/0000,-- 0000/0000
3051 [2] ffff/0,??/? ffff/0,??/? 0000/ffff,-- 0000/ffff
3052 [3] 0xxx/0,??/1 0xxx/0,??/1 1xxx/ffff,-- 1xxx/1fff
3053 [4] ????/1,0y/0 fffe/0,0y/0 1000/1000,0y z000/f000
3054 [5] 0xxx/0,0y/0 0xxx/0,0y/0 1xxx/ffff,0y zxxx/ffff
3055 [6] (none) (none) 1001/1001,-- 1001/1001
3056 [7] (none) (none) (none) 3000/3000
3057 [8] (none) (none) (none) 0000/0fff
3058 [9] (none) (none) (none) 0000/f000
3059 [10] (none) (none) (none) 0000/efff
3060 All numbers in the table are expressed in hexadecimal. The columns in
3062 the table are interpreted as follows:
3063 Criteria
3065 See the list below.
3066 OpenFlow 1.0
3068 OpenFlow 1.1
3069 wwww/x,yy/z means VLAN ID match value wwww with wildcard
3070 bit x and VLAN PCP match value yy with wildcard bit z. ?
3071 means that the given bits are ignored (and conventionally 0
3072 for wwww or yy, conventionally 1 for x or z). ``(none)’’
3073 means that OpenFlow 1.0 (or 1.1) cannot match with these
3074 criteria.
3075 OpenFlow 1.2+
3077 xxxx/yyyy,zz means vlan_vid with value xxxx and mask yyyy,
3078 and vlan_pcp (which is not maskable) with value zz. --
3079 means that vlan_pcp is omitted. ``(none)’’ means that Open‐
3080 Flow 1.2 cannot match with these criteria.
3081 NXM xxxx/yyyy means vlan_tci with value xxxx and mask yyyy.
3083 The matching criteria described by the table are:
3085 [1] Matches any packet, that is, one without an 802.1Q header
3087 or with an 802.1Q header with any TCI value.
3088 [2] Matches only packets without an 802.1Q header.
3090 OpenFlow 1.0 doesn’t define the behavior if dl_vlan is
3092 set to 0xffff and dl_vlan_pcp is not wildcarded. (Open
3093 vSwitch always ignores dl_vlan_pcp when dl_vlan is set to
3094 0xffff.)
3095 OpenFlow 1.1 says explicitly to ignore dl_vlan_pcp when
3097 dl_vlan is set to 0xffff.
3098 OpenFlow 1.2 doesn’t say how to interpret a match with
3100 vlan_vid value 0 and a mask with OFPVID_PRESENT (0x1000)
3101 set to 1 and some other bits in the mask set to 1 also.
3102 Open vSwitch interprets it the same way as a mask of
3103 0x1000.
3104 Any NXM match with vlan_tci value 0 and the CFI bit set
3106 to 1 in the mask is equivalent to the one listed in the
3107 table.
3108 [3] Matches only packets that have an 802.1Q header with VID
3110 xxx (and any PCP).
3111 [4] Matches only packets that have an 802.1Q header with PCP
3113 y (and any VID).
3114 OpenFlow 1.0 doesn’t clearly define the behavior for this
3116 case. Open vSwitch implements it this way.
3117 In the NXM value, z equals (y << 1) | 1.
3119 [5] Matches only packets that have an 802.1Q header with VID
3121 xxx and PCP y.
3122 In the NXM value, z equals (y << 1) | 1.
3124 [6] Matches only packets that have an 802.1Q header with an
3126 odd-numbered VID (and any PCP). Only possible with Open‐
3127 Flow 1.2 and NXM. (This is just an example; one can match
3128 on any desired VID bit pattern.)
3129 [7] Matches only packets that have an 802.1Q header with an
3131 odd-numbered PCP (and any VID). Only possible with NXM.
3132 (This is just an example; one can match on any desired
3133 VID bit pattern.)
3134 [8] Matches packets with no 802.1Q header or with an 802.1Q
3136 header with a VID of 0. Only possible with NXM.
3137 [9] Matches packets with no 802.1Q header or with an 802.1Q
3139 header with a PCP of 0. Only possible with NXM.
3140 [10] Matches packets with no 802.1Q header or with an 802.1Q
3142 header with both VID and PCP of 0. Only possible with
3143 NXM.
3145 Summary:
3146 Name Bytes Mask RW? Prereqs NXM/OXM Support
3147 ─────────── ──────────────── ───── ──── ──────── ──────────────────────
3149 mpls_label 4 (low 20 bits) no yes MPLS OF 1.2+ and OVS 1.11+
3150 mpls_tc 1 (low 3 bits) no yes MPLS OF 1.2+ and OVS 1.11+
3151 mpls_bos 1 (low 1 bits) no no MPLS OF 1.3+ and OVS 1.11+
3153 mpls_ttl 1 no yes MPLS OVS 2.6+
3154 One or more MPLS headers (more commonly called MPLS labels) follow an
3156 Ethernet type field that specifies an MPLS Ethernet type [RFC 3032].
3157 Ethertype 0x8847 is used for all unicast. Multicast MPLS is divided
3158 into two specific classes, one of which uses Ethertype 0x8847 and the
3159 other 0x8848 [RFC 5332].
3160 The most common overall packet format is Ethernet II, shown below (SNAP
3162 encapsulation may be used but is not ordinarily seen in Ethernet net‐
3163 works):
3164 Ethernet MPLS
3166 <------------> <------------>
3167 48 48 16 20 3 1 8
3168 +---+---+------+ +-----+--+-+---+
3169 |dst|src| type | |label|TC|S|TTL| ...
3170 +---+---+------+ +-----+--+-+---+
3171 0x8847
3172 MPLS can be encapsulated inside an 802.1Q header, in which case the
3175 combination looks like this:
3176 Ethernet 802.1Q Ethertype MPLS
3178 <------> <--------> <-------> <------------>
3179 48 48 16 16 16 20 3 1 8
3180 +----+---+ +------+---+ +---------+ +-----+--+-+---+
3181 |dst |src| | TPID |TCI| | type | |label|TC|S|TTL| ...
3182 +----+---+ +------+---+ +---------+ +-----+--+-+---+
3183 0x8100 0x8847
3184 The fields within an MPLS label are:
3187 Label, 20 bits.
3189 An identifier.
3190 Traffic control (TC), 3 bits.
3192 Used for quality of service.
3193 Bottom of stack (BOS), 1 bit (labeled just ``S’’ above).
3195 0 indicates that another MPLS label follows this one.
3196 1 indicates that this MPLS label is the last one in the
3198 stack, so that some other protocol follows this one.
3199 Time to live (TTL), 8 bits.
3201 Each hop across an MPLS network decrements the TTL by 1.
3202 If it reaches 0, the packet is discarded.
3203 OpenFlow does not make the MPLS TTL available as a match
3205 field, but actions are available to set and decrement the
3206 TTL. Open vSwitch 2.6 and later makes the MPLS TTL avail‐
3207 able as an extension.
3208 MPLS Label Stacks
3210 Unlike the other encapsulations supported by OpenFlow and Open vSwitch,
3211 MPLS labels are routinely used in ``stacks’’ two or three deep and
3212 sometimes even deeper. Open vSwitch currently supports up to three
3213 labels.
3214 The OpenFlow specification only supports matching on the outermost MPLS
3216 label at any given time. To match on the second label, one must first
3217 ``pop’’ the outer label and advance to another OpenFlow table, where
3218 the inner label may be matched. To match on the third label, one must
3219 pop the two outer labels, and so on.
3220 MPLS Inner Protocol
3222 Unlike all other forms of encapsulation that Open vSwitch and OpenFlow
3223 support, an MPLS label does not indicate what inner protocol it encap‐
3224 sulates. Different deployments determine the inner protocol in differ‐
3225 ent ways [RFC 3032]:
3226 · A few reserved label values do indicate an inner proto‐
3228 col. Label 0, the ``IPv4 Explicit NULL Label,’’ indicates
3229 inner IPv4. Label 2, the ``IPv6 Explicit NULL Label,’’
3230 indicates inner IPv6.
3231 · Some deployments use a single inner protocol consis‐
3233 tently.
3234 · In some deployments, the inner protocol must be inferred
3236 from the innermost label.
3237 · In some deployments, the inner protocol must be inferred
3239 from the innermost label and the encapsulated data, e.g.
3240 to distinguish between inner IPv4 and IPv6 based on
3241 whether the first nibble of the inner protocol data are 4
3242 or 6. OpenFlow and Open vSwitch do not currently support
3243 these cases.
3244 Open vSwitch and OpenFlow do not infer the inner protocol, even if
3246 reserved label values are in use. Instead, the flow table must specify
3247 the inner protocol at the time it pops the bottommost MPLS label, using
3248 the Ethertype argument to the pop_mpls action.
3249 Field Details
3251 MPLS Label Field
3252 Name: mpls_label
3254 Width: 32 bits (only the least-significant 20 bits may be nonzero)
3255 Format: decimal
3256 Masking: not maskable
3257 Prerequisites: MPLS
3258 Access: read/write
3259 OpenFlow 1.0: not supported
3260 OpenFlow 1.1: yes (exact match only)
3261 OXM: OXM_OF_MPLS_LABEL (34) since OpenFlow 1.2 and Open vSwitch
3263 1.11
3264 NXM: none
3265 The least significant 20 bits hold the ``label’’ field from the MPLS
3267 label. Other bits are zero:
3268 OXM_OF_MPLS_LABEL
3270 <--------------->
3271 12 20
3272 +--------+--------+
3273 | zero | label |
3274 +--------+--------+
3275 0
3276 Most label values are available for any use by deployments. Values
3279 under 16 are reserved.
3280 MPLS Traffic Class Field
3282 Name: mpls_tc
3284 Width: 8 bits (only the least-significant 3 bits may be nonzero)
3285 Format: decimal
3286 Masking: not maskable
3287 Prerequisites: MPLS
3288 Access: read/write
3290 OpenFlow 1.0: not supported
3291 OpenFlow 1.1: yes (exact match only)
3292 OXM: OXM_OF_MPLS_TC [22m(35) since OpenFlow 1.2 and Open vSwitch
3293 1.11
3294 NXM: none
3295 The least significant 3 bits hold the TC field from the MPLS label.
3297 Other bits are zero:
3298 OXM_OF_MPLS_TC
3300 <------------>
3301 5 3
3302 +--------+-----+
3303 | zero | TC |
3304 +--------+-----+
3305 0
3306 This field is intended for use for Quality of Service (QoS) and
3309 Explicit Congestion Notification purposes, but its particular interpre‐
3310 tation is deployment specific.
3311 Before 2009, this field was named EXP and reserved for experimental use
3313 [RFC 5462].
3314 MPLS Bottom of Stack Field
3316 Name: mpls_bos
3318 Width: 8 bits (only the least-significant 1 bits may be nonzero)
3319 Format: decimal
3320 Masking: not maskable
3321 Prerequisites: MPLS
3322 Access: read-only
3323 OpenFlow 1.0: not supported
3324 OpenFlow 1.1: not supported
3326 OXM: OXM_OF_MPLS_BOS (36) since OpenFlow 1.3 and Open vSwitch
3327 1.11
3328 NXM: none
3329 The least significant bit holds the BOS field from the MPLS label.
3331 Other bits are zero:
3332 OXM_OF_MPLS_BOS
3334 <------------->
3335 7 1
3336 +--------+------+
3337 | zero | BOS |
3338 +--------+------+
3339 0
3340 This field is useful as part of processing a series of incoming MPLS
3343 labels. A flow that includes a pop_mpls action should generally match
3344 on mpls_bos:
3345 · When mpls_bos is 1, there is another MPLS label following
3347 this one, so the Ethertype passed to pop_mpls should be
3348 an MPLS Ethertype. For example: table=0, dl_type=0x8847,
3349 mpls_bos=1, actions=pop_mpls:0x8847, goto_table:1
3350 · When mpls_bos is 0, this MPLS label is the last one, so
3352 the Ethertype passed to pop_mpls should be a non-MPLS
3353 Ethertype such as IPv4. For example: table=1,
3354 dl_type=0x8847, mpls_bos=0, actions=pop_mpls:0x0800,
3355 goto_table:2
3356 MPLS Time-to-Live Field
3358 Name: mpls_ttl
3360 Width: 8 bits
3361 Format: decimal
3362 Masking: not maskable
3364 Prerequisites: MPLS
3365 Access: read/write
3366 OpenFlow 1.0: not supported
3367 OpenFlow 1.1: not supported
3368 OXM: none
3369 NXM: NXM_NX_MPLS_TTL (30) since Open vSwitch 2.6
3370 Holds the 8-bit time-to-live field from the MPLS label:
3372 NXM_NX_MPLS_TTL
3374 <------------->
3375 8
3376 +---------------+
3377 | TTL |
3378 +---------------+
3379
3382 Summary:
3383 Name Bytes Mask RW? Prereqs NXM/OXM Support
3384 ────────────────────── ──────────────── ───── ──── ────────── ─────────────────────
3385 ip_src aka nw_src 4 yes yes IPv4 OF 1.2+ and OVS 1.1+
3386 ip_dst aka nw_dst 4 yes yes IPv4 OF 1.2+ and OVS 1.1+
3388 ipv6_src 16 yes yes IPv6 OF 1.2+ and OVS 1.1+
3389 ipv6_dst 16 yes yes IPv6 OF 1.2+ and OVS 1.1+
3390 ipv6_label 4 (low 20 bits) yes yes IPv6 OF 1.2+ and OVS 1.4+
3391 nw_proto aka ip_proto 1 no no IPv4/IPv6 OF 1.2+ and OVS 1.1+
3392 nw_ttl 1 no yes IPv4/IPv6 OVS 1.4+
3393 ip_frag aka nw_frag 1 (low 2 bits) yes no IPv4/IPv6 OVS 1.3+
3395 nw_tos 1 no yes IPv4/IPv6 OVS 1.1+
3396 ip_dscp 1 (low 6 bits) no yes IPv4/IPv6 OF 1.2+ and OVS 1.7+
3397 nw_ecn aka ip_ecn 1 (low 2 bits) no yes IPv4/IPv6 OF 1.2+ and OVS 1.4+
3398 IPv4 Specific Fields
3400 These fields are applicable only to IPv4 flows, that is, flows that
3401 match on the IPv4 Ethertype 0x0800.
3402 IPv4 Source Address Field
3404 Name: ip_src (aka nw_src)
3406 Width: 32 bits
3407 Format: IPv4
3408 Masking: arbitrary bitwise masks
3409 Prerequisites: IPv4
3411 Access: read/write
3412 OpenFlow 1.0: yes (CIDR match only)
3413 OpenFlow 1.1: yes
3414 OXM: OXM_OF_IPV4_SRC [22m(11) since OpenFlow 1.2 and Open
3415 vSwitch 1.7
3416 NXM: NXM_OF_IP_SRC (7) since Open vSwitch 1.1
3417 The source address from the IPv4 header:
3419 Ethernet IPv4
3421 <-----------> <--------------->
3422 48 48 16 8 32 32
3423 +---+---+-----+ +---+-----+---+---+
3424 |dst|src|type | |...|proto|src|dst| ...
3425 +---+---+-----+ +---+-----+---+---+
3426 0x800
3427 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3430 matches on nw_src as actually referring to the ARP SPA.
3431 IPv4 Destination Address Field
3433 Name: ip_dst (aka nw_dst)
3435 Width: 32 bits
3436 Format: IPv4
3437 Masking: arbitrary bitwise masks
3438 Prerequisites: IPv4
3439 Access: read/write
3440 OpenFlow 1.0: yes (CIDR match only)
3441 OpenFlow 1.1: yes
3443 OXM: OXM_OF_IPV4_DST [22m(12) since OpenFlow 1.2 and Open
3444 vSwitch 1.7
3445 NXM: NXM_OF_IP_DST (8) since Open vSwitch 1.1
3446 The destination address from the IPv4 header:
3448 Ethernet IPv4
3450 <-----------> <--------------->
3451 48 48 16 8 32 32
3452 +---+---+-----+ +---+-----+---+---+
3453 |dst|src|type | |...|proto|src|dst| ...
3454 +---+---+-----+ +---+-----+---+---+
3455 0x800
3456 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3459 matches on nw_dst as actually referring to the ARP TPA.
3460 IPv6 Specific Fields
3462 These fields apply only to IPv6 flows, that is, flows that match on the
3463 IPv6 Ethertype 0x86dd.
3464 IPv6 Source Address Field
3466 Name: ipv6_src
3468 Width: 128 bits
3469 Format: IPv6
3470 Masking: arbitrary bitwise masks
3471 Prerequisites: IPv6
3472 Access: read/write
3473 OpenFlow 1.0: not supported
3475 OpenFlow 1.1: not supported
3476 OXM: OXM_OF_IPV6_SRC [22m(26) since OpenFlow 1.2 and Open
3477 vSwitch 1.1
3478 NXM: NXM_NX_IPV6_SRC (19) since Open vSwitch 1.1
3479 The source address from the IPv6 header:
3481 Ethernet IPv6
3483 <------------> <-------------->
3484 48 48 16 8 128 128
3485 +---+---+------+ +---+----+---+---+
3486 |dst|src| type | |...|next|src|dst| ...
3487 +---+---+------+ +---+----+---+---+
3488 0x86dd
3489 Open vSwitch 1.8 added support for bitwise matching; earlier versions
3492 supported only CIDR masks.
3493 IPv6 Destination Address Field
3495 Name: ipv6_dst
3497 Width: 128 bits
3499 Format: IPv6
3500 Masking: arbitrary bitwise masks
3501 Prerequisites: IPv6
3502 Access: read/write
3503 OpenFlow 1.0: not supported
3504 OpenFlow 1.1: not supported
3505 OXM: OXM_OF_IPV6_DST [22m(27) since OpenFlow 1.2 and Open
3507 vSwitch 1.1
3508 NXM: NXM_NX_IPV6_DST (20) since Open vSwitch 1.1
3509 The destination address from the IPv6 header:
3511 Ethernet IPv6
3513 <------------> <-------------->
3514 48 48 16 8 128 128
3515 +---+---+------+ +---+----+---+---+
3516 |dst|src| type | |...|next|src|dst| ...
3517 +---+---+------+ +---+----+---+---+
3518 0x86dd
3519 Open vSwitch 1.8 added support for bitwise matching; earlier versions
3522 supported only CIDR masks.
3523 IPv6 Flow Label Field
3525 Name: ipv6_label
3527 Width: 32 bits (only the least-significant 20 bits may be nonzero)
3528 Format: hexadecimal
3529 Masking: arbitrary bitwise masks
3531 Prerequisites: IPv6
3532 Access: read/write
3533 OpenFlow 1.0: not supported
3534 OpenFlow 1.1: not supported
3535 OXM: OXM_OF_IPV6_FLABEL (28) since OpenFlow 1.2 and Open vSwitch
3536 1.7
3537 NXM: NXM_NX_IPV6_LABEL (27) since Open vSwitch 1.4
3539 The least significant 20 bits hold the flow label field from the IPv6
3541 header. Other bits are zero:
3542 OXM_OF_IPV6_FLABEL
3544 <---------------->
3545 12 20
3546 +--------+---------+
3547 | zero | label |
3548 +--------+---------+
3549 0
3550 IPv4/IPv6 Fields
3553 These fields exist with at least approximately the same meaning in both
3554 IPv4 and IPv6, so they are treated as a single field for matching pur‐
3555 poses. Any flow that matches on the IPv4 Ethertype 0x0800 or the IPv6
3556 Ethertype 0x86dd may match on these fields.
3557 IPv4/v6 Protocol Field
3559 Name: nw_proto (aka ip_proto)
3561 Width: 8 bits
3562 Format: decimal
3563 Masking: not maskable
3565 Prerequisites: IPv4/IPv6
3566 Access: read-only
3567 OpenFlow 1.0: yes (exact match only)
3568 OpenFlow 1.1: yes (exact match only)
3569 OXM: OXM_OF_IP_PROTO [22m(10) since OpenFlow 1.2 and Open
3570 vSwitch 1.7
3571 NXM: NXM_OF_IP_PROTO (6) since Open vSwitch 1.1
3572 Matches the IPv4 or IPv6 protocol type.
3574 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3576 matches on nw_proto as actually referring to the ARP opcode. The ARP
3577 opcode is a 16-bit field, so for matching purposes ARP opcodes greater
3578 than 255 are treated as 0; this works adequately because in practice
3579 ARP and RARP only use opcodes 1 through 4.
3580 IPv4/v6 TTL/Hop Limit Field
3582 Name: nw_ttl
3584 Width: 8 bits
3585 Format: decimal
3586 Masking: not maskable
3587 Prerequisites: IPv4/IPv6
3588 Access: read/write
3589 OpenFlow 1.0: not supported
3590 OpenFlow 1.1: not supported
3592 OXM: none
3593 NXM: NXM_NX_IP_TTL (29) since Open vSwitch 1.4
3594 The main reason to match on the TTL or hop limit field is to detect
3596 whether a dec_ttl action will fail due to a TTL exceeded error. Another
3597 way that a controller can detect TTL exceeded is to listen for
3598 OFPR_INVALID_TTL ``packet-in’’ messages via OpenFlow.
3599 IPv4/v6 Fragment Bitmask Field
3601 Name: ip_frag (aka nw_frag)
3603 Width: 8 bits (only the least-significant 2 bits may be nonzero)
3604 Format: frag
3605 Masking: arbitrary bitwise masks
3606 Prerequisites: IPv4/IPv6
3607 Access: read-only
3608 OpenFlow 1.0: not supported
3610 OpenFlow 1.1: not supported
3611 OXM: none
3612 NXM: NXM_NX_IP_FRAG (26) since Open vSwitch 1.3
3613 Specifies what kinds of IP fragments or non-fragments to match. The
3615 value for this field is most conveniently specified as one of the fol‐
3616 lowing:
3617 no Match only non-fragmented packets.
3619 yes Matches all fragments.
3621 first Matches only fragments with offset 0.
3623 later Matches only fragments with nonzero offset.
3625 not_later
3627 Matches non-fragmented packets and fragments with zero
3628 offset.
3629 The field is internally formatted as 2 bits: bit 0 is 1 for an IP frag‐
3631 ment with any offset (and otherwise 0), and bit 1 is 1 for an IP frag‐
3632 ment with nonzero offset (and otherwise 0), like so:
3633 NXM_NX_IP_FRAG
3635 <------------>
3636 6 1 1
3637 +----+-----+---+
3638 |zero|later|any|
3639 +----+-----+---+
3640 0
3641 Even though 2 bits have 4 possible values, this field only uses 3 of
3644 them:
3645 · A packet that is not an IP fragment has value 0.
3647 · A packet that is an IP fragment with offset 0 (the first
3649 fragment) has bit 0 set and thus value 1.
3650 · A packet that is an IP fragment with nonzero offset has
3652 bits 0 and 1 set and thus value 3.
3653 The switch may reject matches against values that can never appear.
3655 It is important to understand how this field interacts with the Open‐
3657 Flow fragment handling mode:
3658 · In OFPC_FRAG_DROP mode, the OpenFlow switch drops all IP
3660 fragments before they reach the flow table, so every
3661 packet that is available for matching will have value 0
3662 in this field.
3663 · Open vSwitch does not implement OFPC_FRAG_REASM mode, but
3665 if it did then IP fragments would be reassembled before
3666 they reached the flow table and again every packet avail‐
3667 able for matching would always have value 0.
3668 · In OFPC_FRAG_NORMAL mode, all three values are possible,
3670 but OpenFlow 1.0 says that fragments’ transport ports are
3671 always 0, even for the first fragment, so this does not
3672 provide much extra information.
3673 · In OFPC_FRAG_NX_MATCH mode, all three values are possi‐
3675 ble. For fragments with offset 0, Open vSwitch makes L4
3676 header information available.
3677 Thus, this field is likely to be most useful for an Open vSwitch switch
3679 configured in OFPC_FRAG_NX_MATCH mode. See the description of the
3680 set-frags command in ovs-ofctl(8), for more details.
3681 IPv4/IPv6 TOS Fields
3683 IPv4 and IPv6 contain a one-byte ``type of service’’ or TOS field that
3685 has the following format:
3686 type of service
3688 <------------->
3689 6 2
3690 +--------+------+
3691 | DSCP | ECN |
3692 +--------+------+
3693 IPv4/v6 DSCP (Bits 2-7) Field
3696 Name: nw_tos
3698 Width: 8 bits
3699 Format: decimal
3700 Masking: not maskable
3701 Prerequisites: IPv4/IPv6
3702 Access: read/write
3703 OpenFlow 1.0: yes (exact match only)
3704 OpenFlow 1.1: yes (exact match only)
3705 OXM: none
3707 NXM: NXM_OF_IP_TOS (5) since Open vSwitch 1.1
3708 This field is the TOS byte with the two ECN bits cleared to 0:
3710 NXM_OF_IP_TOS
3712 <----------->
3713 6 2
3714 +------+------+
3715 | DSCP | zero |
3716 +------+------+
3717 0
3718 IPv4/v6 DSCP (Bits 0-5) Field
3721 Name: ip_dscp
3723 Width: 8 bits (only the least-significant 6 bits may be nonzero)
3724 Format: decimal
3725 Masking: not maskable
3726 Prerequisites: IPv4/IPv6
3727 Access: read/write
3729 OpenFlow 1.0: yes (exact match only)
3730 OpenFlow 1.1: yes (exact match only)
3731 OXM: OXM_OF_IP_DSCP [22m(8) since OpenFlow 1.2 and Open vSwitch
3732 1.7
3733 NXM: none
3734 This field is the TOS byte shifted right to put the DSCP bits in the 6
3736 least-significant bits:
3737 OXM_OF_IP_DSCP
3739 <------------>
3740 2 6
3741 +-------+------+
3742 | zero | DSCP |
3743 +-------+------+
3744 0
3745 IPv4/v6 ECN Field
3748 Name: nw_ecn (aka ip_ecn)
3751 Width: 8 bits (only the least-significant 2 bits may be nonzero)
3752 Format: decimal
3753 Masking: not maskable
3754 Prerequisites: IPv4/IPv6
3755 Access: read/write
3756 OpenFlow 1.0: not supported
3757 OpenFlow 1.1: yes (exact match only)
3758 OXM: OXM_OF_IP_ECN (9) since OpenFlow 1.2 and Open vSwitch 1.7
3759 NXM: NXM_NX_IP_ECN (28) since Open vSwitch 1.4
3760 This field is the TOS byte with the DSCP bits cleared to 0:
3762 OXM_OF_IP_ECN
3764 <----------->
3765 6 2
3766 +-------+-----+
3767 | zero | ECN |
3768 +-------+-----+
3769 0
3770
3773 Summary:
3774 Name Bytes Mask RW? Prereqs NXM/OXM Support
3775 ──────── ────── ───── ──── ──────── ─────────────────────
3776 arp_op 2 no yes ARP OF 1.2+ and OVS 1.1+
3777 arp_spa 4 yes yes ARP OF 1.2+ and OVS 1.1+
3778 arp_tpa 4 yes yes ARP OF 1.2+ and OVS 1.1+
3779 arp_sha 6 yes yes ARP OF 1.2+ and OVS 1.1+
3780 arp_tha 6 yes yes ARP OF 1.2+ and OVS 1.1+
3782 In theory, Address Resolution Protocol, or ARP, is a generic protocol
3784 generic protocol that can be used to obtain the hardware address that
3785 corresponds to any higher-level protocol address. In contemporary
3786 usage, ARP is used only in Ethernet networks to obtain the Ethernet
3787 address for a given IPv4 address. OpenFlow and Open vSwitch only sup‐
3788 port this usage of ARP. For this use case, an ARP packet has the fol‐
3789 lowing format, with the ARP fields exposed as Open vSwitch fields high‐
3790 lighted:
3791 Ethernet ARP
3793 <-----------> <---------------------------------->
3794 48 48 16 16 16 8 8 16 48 16 48 16
3795 +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3796 |dst|src|type | |hrd| pro |hln|pln|op|sha|spa|tha|tpa|
3797 +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3798 0x806 1 0x800 6 4
3799 The ARP fields are also used for RARP, the Reverse Address Resolution
3802 Protocol, which shares ARP’s wire format.
3803 ARP Opcode Field
3805 Name: arp_op
3807 Width: 16 bits
3808 Format: decimal
3809 Masking: not maskable
3810 Prerequisites: ARP
3812 Access: read/write
3813 OpenFlow 1.0: yes (exact match only)
3814 OpenFlow 1.1: yes (exact match only)
3815 OXM: OXM_OF_ARP_OP (21) since OpenFlow 1.2 and Open vSwitch
3816 1.7
3817 NXM: NXM_OF_ARP_OP (15) since Open vSwitch 1.1
3818 Even though this is a 16-bit field, Open vSwitch does not support ARP
3820 opcodes greater than 255; it treats them to zero. This works adequately
3821 because in practice ARP and RARP only use opcodes 1 through 4.
3822 ARP Source IPv4 Address Field
3824 Name: arp_spa
3826 Width: 32 bits
3827 Format: IPv4
3828 Masking: arbitrary bitwise masks
3829 Prerequisites: ARP
3830 Access: read/write
3832 OpenFlow 1.0: yes (CIDR match only)
3833 OpenFlow 1.1: yes
3834 OXM: OXM_OF_ARP_SPA [22m(22) since OpenFlow 1.2 and Open
3835 vSwitch 1.7
3836 NXM: NXM_OF_ARP_SPA (16) since Open vSwitch 1.1
3837 ARP Target IPv4 Address Field
3839 Name: arp_tpa
3842 Width: 32 bits
3843 Format: IPv4
3844 Masking: arbitrary bitwise masks
3845 Prerequisites: ARP
3846 Access: read/write
3847 OpenFlow 1.0: yes (CIDR match only)
3848 OpenFlow 1.1: yes
3849 OXM: OXM_OF_ARP_TPA [22m(23) since OpenFlow 1.2 and Open
3852 vSwitch 1.7
3853 NXM: NXM_OF_ARP_TPA (17) since Open vSwitch 1.1
3854 ARP Source Ethernet Address Field
3856 Name: arp_sha
3858 Width: 48 bits
3859 Format: Ethernet
3860 Masking: arbitrary bitwise masks
3862 Prerequisites: ARP
3863 Access: read/write
3864 OpenFlow 1.0: not supported
3865 OpenFlow 1.1: not supported
3866 OXM: OXM_OF_ARP_SHA [22m(24) since OpenFlow 1.2 and Open
3867 vSwitch 1.7
3868 NXM: NXM_NX_ARP_SHA (17) since Open vSwitch 1.1
3869 ARP Target Ethernet Address Field
3871 Name: arp_tha
3873 Width: 48 bits
3874 Format: Ethernet
3875 Masking: arbitrary bitwise masks
3876 Prerequisites: ARP
3877 Access: read/write
3878 OpenFlow 1.0: not supported
3879 OpenFlow 1.1: not supported
3880 OXM: OXM_OF_ARP_THA [22m(25) since OpenFlow 1.2 and Open
3882 vSwitch 1.7
3883 NXM: NXM_NX_ARP_THA (18) since Open vSwitch 1.1
3884
3886 Summary:
3887 Name Bytes Mask RW? Prereqs NXM/OXM Support
3888 ───────────────── ──────────────── ───── ──── ──────── ────────────────
3890 nsh_flags 1 yes yes NSH OVS 2.8+
3891 nsh_ttl 1 no yes NSH OVS 2.9+
3892 nsh_mdtype 1 no no NSH OVS 2.8+
3893 nsh_np 1 no no NSH OVS 2.8+
3895 nsh_spi aka nsp 4 (low 24 bits) no yes NSH OVS 2.8+
3896 nsh_si aka nsi 1 no yes NSH OVS 2.8+
3897 nsh_c1 aka nshc1 4 yes yes NSH OVS 2.8+
3898 nsh_c2 aka nshc2 4 yes yes NSH OVS 2.8+
3900 nsh_c3 aka nshc3 4 yes yes NSH OVS 2.8+
3901 nsh_c4 aka nshc4 4 yes yes NSH OVS 2.8+
3902 Service functions are widely deployed and essential in many networks.
3904 These service functions provide a range of features such as security,
3905 WAN acceleration, and server load balancing. Service functions may be
3906 instantiated at different points in the network infrastructure such as
3907 the wide area network, data center, and so forth.
3908 Prior to development of the SFC architecture [RFC 7665] and the proto‐
3910 col specified in this document, current service function deployment
3911 models have been relatively static and bound to topology for insertion
3912 and policy selection. Furthermore, they do not adapt well to elastic
3913 service environments enabled by virtualization.
3914 New data center network and cloud architectures require more flexible
3916 service function deployment models. Additionally, the transition to
3917 virtual platforms demands an agile service insertion model that sup‐
3918 ports dynamic and elastic service delivery. Specifically, the following
3919 functions are necessary:
3920 1. The movement of service functions and application workloads
3922 in the network.
3923 2. The ability to easily bind service policy to granular infor‐
3925 mation, such as per-subscriber state.
3926 3. The capability to steer traffic to the requisite service
3928 function(s).
3929 The Network Service Header (NSH) specification defines a new data plane
3931 protocol, which is an encapsulation for service function chains. The
3932 NSH is designed to encapsulate an original packet or frame, and in turn
3933 be encapsulated by an outer transport encapsulation (which is used to
3934 deliver the NSH to NSH-aware network elements), as shown below:
3935 +-----------------------+----------------------------+---------------------+
3937 |Transport Encapsulation|Network Service Header (NSH)|Original Packet/Frame|
3938 +-----------------------+----------------------------+---------------------+
3939 The NSH is composed of the following elements:
3942 1. Service Function Path identification.
3944 2. Indication of location within a Service Function Path.
3946 3. Optional, per packet metadata (fixed length or variable).
3948 [RFC 7665] provides an overview of a service chaining architecture that
3950 clearly defines the roles of the various elements and the scope of a
3951 service function chaining encapsulation. Figure 3 of [RFC 7665] depicts
3952 the SFC architectural components after classification. The NSH is the
3953 SFC encapsulation referenced in [RFC 7665].
3954 flags field (2 bits) Field
3956 Name: nsh_flags
3958 Width: 8 bits
3959 Format: decimal
3960 Masking: arbitrary bitwise masks
3961 Prerequisites: NSH
3962 Access: read/write
3964 OpenFlow 1.0: not supported
3965 OpenFlow 1.1: not supported
3966 OXM: none
3967 NXM: NXOXM_NSH_FLAGS (1) since Open vSwitch 2.8
3968 TTL field (6 bits) Field
3970 Name: nsh_ttl
3972 Width: 8 bits
3973 Format: decimal
3974 Masking: not maskable
3976 Prerequisites: NSH
3977 Access: read/write
3978 OpenFlow 1.0: not supported
3979 OpenFlow 1.1: not supported
3980 OXM: none
3982 NXM: NXOXM_NSH_TTL (10) since Open vSwitch 2.9
3983 mdtype field (8 bits) Field
3985 Name: nsh_mdtype
3988 Width: 8 bits
3989 Format: decimal
3990 Masking: not maskable
3991 Prerequisites: NSH
3992 Access: read-only
3994 OpenFlow 1.0: not supported
3995 OpenFlow 1.1: not supported
3996 OXM: none
3997 NXM: NXOXM_NSH_MDTYPE (2) since Open vSwitch 2.8
3998 np (next protocol) field (8 bits) Field
4000 Name: nsh_np
4002 Width: 8 bits
4003 Format: decimal
4004 Masking: not maskable
4006 Prerequisites: NSH
4007 Access: read-only
4008 OpenFlow 1.0: not supported
4009 OpenFlow 1.1: not supported
4010 OXM: none
4012 NXM: NXOXM_NSH_NP (3) since Open vSwitch 2.8
4013 spi (service path identifier) field (24 bits) Field
4015 Name: nsh_spi (aka nsp)
4018 Width: 32 bits (only the least-significant 24 bits may be nonzero)
4019 Format: hexadecimal
4020 Masking: not maskable
4021 Prerequisites: NSH
4022 Access: read/write
4024 OpenFlow 1.0: not supported
4025 OpenFlow 1.1: not supported
4026 OXM: none
4027 NXM: NXOXM_NSH_SPI (4) since Open vSwitch 2.8
4028 si (service index) field (8 bits) Field
4030 Name: nsh_si (aka nsi)
4032 Width: 8 bits
4033 Format: decimal
4034 Masking: not maskable
4036 Prerequisites: NSH
4037 Access: read/write
4038 OpenFlow 1.0: not supported
4039 OpenFlow 1.1: not supported
4040 OXM: none
4042 NXM: NXOXM_NSH_SI (5) since Open vSwitch 2.8
4043 c1 (Network Platform Context) field (32 bits) Field
4045 Name: nsh_c1 (aka nshc1)
4048 Width: 32 bits
4049 Format: hexadecimal
4050 Masking: arbitrary bitwise masks
4051 Prerequisites: NSH
4052 Access: read/write
4054 OpenFlow 1.0: not supported
4055 OpenFlow 1.1: not supported
4056 OXM: none
4057 NXM: NXOXM_NSH_C1 (6) since Open vSwitch 2.8
4058 c2 (Network Shared Context) field (32 bits) Field
4060 Name: nsh_c2 (aka nshc2)
4062 Width: 32 bits
4063 Format: hexadecimal
4064 Masking: arbitrary bitwise masks
4066 Prerequisites: NSH
4067 Access: read/write
4068 OpenFlow 1.0: not supported
4069 OpenFlow 1.1: not supported
4070 OXM: none
4072 NXM: NXOXM_NSH_C2 (7) since Open vSwitch 2.8
4073 c3 (Service Platform Context) field (32 bits) Field
4075 Name: nsh_c3 (aka nshc3)
4078 Width: 32 bits
4079 Format: hexadecimal
4080 Masking: arbitrary bitwise masks
4081 Prerequisites: NSH
4082 Access: read/write
4084 OpenFlow 1.0: not supported
4085 OpenFlow 1.1: not supported
4086 OXM: none
4087 NXM: NXOXM_NSH_C3 (8) since Open vSwitch 2.8
4088 c4 (Service Shared Context) field (32 bits) Field
4090 Name: nsh_c4 (aka nshc4)
4092 Width: 32 bits
4093 Format: hexadecimal
4094 Masking: arbitrary bitwise masks
4096 Prerequisites: NSH
4097 Access: read/write
4098 OpenFlow 1.0: not supported
4099 OpenFlow 1.1: not supported
4100 OXM: none
4102 NXM: NXOXM_NSH_C4 (9) since Open vSwitch 2.8
4103
4105 Summary:
4106 Name Bytes Mask RW? Prereqs NXM/OXM Support
4107 ─────────────────── ──────────────── ───── ──── ──────── ─────────────────────
4109 tcp_src aka tp_src 2 yes yes TCP OF 1.2+ and OVS 1.1+
4110 tcp_dst aka tp_dst 2 yes yes TCP OF 1.2+ and OVS 1.1+
4111 tcp_flags 2 (low 12 bits) yes no TCP OF 1.3+ and OVS 2.1+
4112 udp_src 2 yes yes UDP OF 1.2+ and OVS 1.1+
4114 udp_dst 2 yes yes UDP OF 1.2+ and OVS 1.1+
4115 sctp_src 2 yes yes SCTP OF 1.2+ and OVS 2.0+
4116 sctp_dst 2 yes yes SCTP OF 1.2+ and OVS 2.0+
4117 For matching purposes, no distinction is made whether these protocols
4119 are encapsulated within IPv4 or IPv6.
4120 TCP
4122 The following diagram shows TCP within IPv4. Open vSwitch also supports
4123 TCP in IPv6. Only TCP fields implemented as Open vSwitch fields are
4124 shown:
4125 Ethernet IPv4 TCP
4127 <-----------> <---------------> <------------------->
4128 48 48 16 8 32 32 16 16 12
4129 +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4130 |dst|src|type | |...|proto|src|dst| |src|dst|...|flags|...| ...
4131 +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4132 0x800 6
4133 TCP Source Port Field
4136 Name: tcp_src (aka tp_src)
4138 Width: 16 bits
4139 Format: decimal
4140 Masking: arbitrary bitwise masks
4141 Prerequisites: TCP
4143 Access: read/write
4144 OpenFlow 1.0: yes (exact match only)
4145 OpenFlow 1.1: yes (exact match only)
4146 OXM: OXM_OF_TCP_SRC [22m(13) since OpenFlow 1.2 and Open
4149 vSwitch 1.7
4150 NXM: NXM_OF_TCP_SRC (9) since Open vSwitch 1.1
4151 Open vSwitch 1.6 added support for bitwise matching.
4153 TCP Destination Port Field
4155 Name: tcp_dst (aka tp_dst)
4157 Width: 16 bits
4158 Format: decimal
4159 Masking: arbitrary bitwise masks
4161 Prerequisites: TCP
4162 Access: read/write
4163 OpenFlow 1.0: yes (exact match only)
4164 OpenFlow 1.1: yes (exact match only)
4165 OXM: OXM_OF_TCP_DST [22m(14) since OpenFlow 1.2 and Open
4167 vSwitch 1.7
4168 NXM: NXM_OF_TCP_DST (10) since Open vSwitch 1.1
4169 Open vSwitch 1.6 added support for bitwise matching.
4171 TCP Flags Field
4173 Name: tcp_flags
4175 Width: 16 bits (only the least-significant 12 bits may be nonzero)
4176 Format: TCP flags
4177 Masking: arbitrary bitwise masks
4179 Prerequisites: TCP
4180 Access: read-only
4181 OpenFlow 1.0: not supported
4182 OpenFlow 1.1: not supported
4183 OXM: ONFOXM_ET_TCP_FLAGS [22m(42) since OpenFlow 1.3 and Open
4185 vSwitch 2.4; OXM_OF_TCP_FLAGS (42) since OpenFlow 1.5 and
4186 Open vSwitch 2.3
4187 NXM: NXM_NX_TCP_FLAGS (34) since Open vSwitch 2.1
4188 This field holds the TCP flags. TCP currently defines 9 flag bits. An
4190 additional 3 bits are reserved. For more information, see [RFC 793],
4191 [RFC 3168], and [RFC 3540].
4192 Matches on this field are most conveniently written in terms of sym‐
4194 bolic names (given in the diagram below), each preceded by either + for
4195 a flag that must be set, or - for a flag that must be unset, without
4196 any other delimiters between the flags. Flags not mentioned are wild‐
4197 carded. For example, tcp,tcp_flags=+syn-ack matches TCP SYNs that are
4198 not ACKs, and tcp,tcp_flags=+[200] matches TCP packets with the
4199 reserved [200] flag set. Matches can also be written as flags/mask,
4200 where flags and mask are 16-bit numbers in decimal or in hexadecimal
4201 prefixed by 0x.
4202 The flag bits are:
4204 reserved later RFCs RFC 793
4206 <---------------> <--------> <--------------------->
4207 4 1 1 1 1 1 1 1 1 1 1 1 1
4208 +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4209 |zero|[800]|[400]|[200]|NS|CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|
4210 +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4211 0
4212 UDP
4215 The following diagram shows UDP within IPv4. Open vSwitch also supports
4216 UDP in IPv6. Only UDP fields that Open vSwitch exposes as fields are
4217 shown:
4218 Ethernet IPv4 UDP
4220 <-----------> <---------------> <--------->
4221 48 48 16 8 32 32 16 16
4222 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4223 |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4224 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4225 0x800 17
4226 UDP Source Port Field
4229 Name: udp_src
4231 Width: 16 bits
4233 Format: decimal
4234 Masking: arbitrary bitwise masks
4235 Prerequisites: UDP
4236 Access: read/write
4237 OpenFlow 1.0: yes (exact match only)
4239 OpenFlow 1.1: yes (exact match only)
4240 OXM: OXM_OF_UDP_SRC [22m(15) since OpenFlow 1.2 and Open
4241 vSwitch 1.7
4242 NXM: NXM_OF_UDP_SRC (11) since Open vSwitch 1.1
4243 UDP Destination Port Field
4245 Name: udp_dst
4247 Width: 16 bits
4248 Format: decimal
4249 Masking: arbitrary bitwise masks
4251 Prerequisites: UDP
4252 Access: read/write
4253 OpenFlow 1.0: yes (exact match only)
4254 OpenFlow 1.1: yes (exact match only)
4255 OXM: OXM_OF_UDP_DST [22m(16) since OpenFlow 1.2 and Open
4257 vSwitch 1.7
4258 NXM: NXM_OF_UDP_DST (12) since Open vSwitch 1.1
4259 SCTP
4261 The following diagram shows SCTP within IPv4. Open vSwitch also sup‐
4262 ports SCTP in IPv6. Only SCTP fields that Open vSwitch exposes as
4263 fields are shown:
4264 Ethernet IPv4 SCTP
4266 <-----------> <---------------> <--------->
4267 48 48 16 8 32 32 16 16
4268 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4269 |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4270 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4271 0x800 132
4272 SCTP Source Port Field
4275 Name: sctp_src
4278 Width: 16 bits
4279 Format: decimal
4280 Masking: arbitrary bitwise masks
4281 Prerequisites: SCTP
4282 Access: read/write
4283 OpenFlow 1.0: not supported
4285 OpenFlow 1.1: yes (exact match only)
4286 OXM: OXM_OF_SCTP_SRC [22m(17) since OpenFlow 1.2 and Open
4287 vSwitch 2.0
4288 NXM: none
4289 SCTP Destination Port Field
4291 Name: sctp_dst
4293 Width: 16 bits
4294 Format: decimal
4295 Masking: arbitrary bitwise masks
4296 Prerequisites: SCTP
4297 Access: read/write
4299 OpenFlow 1.0: not supported
4300 OpenFlow 1.1: yes (exact match only)
4301 OXM: OXM_OF_SCTP_DST [22m(18) since OpenFlow 1.2 and Open
4302 vSwitch 2.0
4303 NXM: none
4304
4306 Summary:
4307 Name Bytes Mask RW? Prereqs NXM/OXM Support
4308 ──────────────── ────── ───── ──── ─────────── ─────────────────────
4309 icmp_type 1 no yes ICMPv4 OF 1.2+ and OVS 1.1+
4311 icmp_code 1 no yes ICMPv4 OF 1.2+ and OVS 1.1+
4312 icmpv6_type 1 no yes ICMPv6 OF 1.2+ and OVS 1.1+
4313 icmpv6_code 1 no yes ICMPv6 OF 1.2+ and OVS 1.1+
4314 nd_target 16 yes yes ND OF 1.2+ and OVS 1.1+
4315 nd_sll 6 yes yes ND solicit OF 1.2+ and OVS 1.1+
4317 nd_tll 6 yes yes ND advert OF 1.2+ and OVS 1.1+
4318 nd_reserved 4 no yes ND OVS 2.11+
4319 nd_options_type 1 no yes ND OVS 2.11+
4320 ICMPv4
4322 Ethernet IPv4 ICMPv4
4323 <-----------> <---------------> <----------->
4324 48 48 16 8 32 32 8 8
4325 +---+---+-----+ +---+-----+---+---+ +----+----+---+
4326 |dst|src|type | |...|proto|src|dst| |type|code|...| ...
4327 +---+---+-----+ +---+-----+---+---+ +----+----+---+
4328 0x800 1
4329 ICMPv4 Type Field
4332 Name: icmp_type
4334 Width: 8 bits
4335 Format: decimal
4336 Masking: not maskable
4337 Prerequisites: ICMPv4
4338 Access: read/write
4339 OpenFlow 1.0: yes (exact match only)
4341 OpenFlow 1.1: yes (exact match only)
4342 OXM: OXM_OF_ICMPV4_TYPE (19) since OpenFlow 1.2 and Open
4343 vSwitch 1.7
4344 NXM: NXM_OF_ICMP_TYPE (13) since Open vSwitch 1.1
4345 For historical reasons, in an ICMPv4 flow, Open vSwitch interprets
4347 matches on tp_src as actually referring to the ICMP type.
4348 ICMPv4 Code Field
4350 Name: icmp_code
4352 Width: 8 bits
4353 Format: decimal
4354 Masking: not maskable
4355 Prerequisites: ICMPv4
4357 Access: read/write
4358 OpenFlow 1.0: yes (exact match only)
4359 OpenFlow 1.1: yes (exact match only)
4360 OXM: OXM_OF_ICMPV4_CODE (20) since OpenFlow 1.2 and Open
4361 vSwitch 1.7
4362 NXM: NXM_OF_ICMP_CODE (14) since Open vSwitch 1.1
4363 For historical reasons, in an ICMPv4 flow, Open vSwitch interprets
4365 matches on tp_dst as actually referring to the ICMP code.
4366 ICMPv6
4368 Ethernet IPv6 ICMPv6
4369 <------------> <--------------> <----------->
4370 48 48 16 8 128 128 8 8
4371 +---+---+------+ +---+----+---+---+ +----+----+---+
4372 |dst|src| type | |...|next|src|dst| |type|code|...| ...
4373 +---+---+------+ +---+----+---+---+ +----+----+---+
4374 0x86dd 58
4375 ICMPv6 Type Field
4378 Name: icmpv6_type
4381 Width: 8 bits
4382 Format: decimal
4383 Masking: not maskable
4384 Prerequisites: ICMPv6
4385 Access: read/write
4386 OpenFlow 1.0: not supported
4387 OpenFlow 1.1: not supported
4389 OXM: OXM_OF_ICMPV6_TYPE (29) since OpenFlow 1.2 and Open
4390 vSwitch 1.7
4391 NXM: NXM_NX_ICMPV6_TYPE (21) since Open vSwitch 1.1
4392 ICMPv6 Code Field
4394 Name: icmpv6_code
4397 Width: 8 bits
4398 Format: decimal
4399 Masking: not maskable
4400 Prerequisites: ICMPv6
4401 Access: read/write
4402 OpenFlow 1.0: not supported
4403 OpenFlow 1.1: not supported
4405 OXM: OXM_OF_ICMPV6_CODE [22m(30) since OpenFlow 1.2 and Open
4406 vSwitch 1.7
4407 NXM: NXM_NX_ICMPV6_CODE (22) since Open vSwitch 1.1
4408 ICMPv6 Neighbor Discovery
4410 Ethernet IPv6 ICMPv6 ICMPv6 ND
4411 <------------> <--------------> <--------------> <--------------->
4412 48 48 16 8 128 128 8 8 128
4413 +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4414 |dst|src| type | |...|next|src|dst| | type |code|...| |target|option ...|
4415 +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4416 0x86dd 58 135/136 0
4417 ICMPv6 Neighbor Discovery Target IPv6 Field
4420 Name: nd_target
4422 Width: 128 bits
4423 Format: IPv6
4424 Masking: arbitrary bitwise masks
4425 Prerequisites: ND
4426 Access: read/write
4427 OpenFlow 1.0: not supported
4429 OpenFlow 1.1: not supported
4430 OXM: OXM_OF_IPV6_ND_TARGET (31) since OpenFlow 1.2 and Open
4431 vSwitch 1.7
4432 NXM: NXM_NX_ND_TARGET (23) since Open vSwitch 1.1
4433 ICMPv6 Neighbor Discovery Source Ethernet Address Field
4435 Name: nd_sll
4437 Width: 48 bits
4438 Format: Ethernet
4439 Masking: arbitrary bitwise masks
4440 Prerequisites: ND solicit
4441 Access: read/write
4442 OpenFlow 1.0: not supported
4443 OpenFlow 1.1: not supported
4445 OXM: OXM_OF_IPV6_ND_SLL [22m(32) since OpenFlow 1.2 and Open
4446 vSwitch 1.7
4447 NXM: NXM_NX_ND_SLL (24) since Open vSwitch 1.1
4448 ICMPv6 Neighbor Discovery Target Ethernet Address Field
4450 Name: nd_tll
4453 Width: 48 bits
4454 Format: Ethernet
4455 Masking: arbitrary bitwise masks
4456 Prerequisites: ND advert
4457 Access: read/write
4458 OpenFlow 1.0: not supported
4459 OpenFlow 1.1: not supported
4461 OXM: OXM_OF_IPV6_ND_TLL (33) since OpenFlow 1.2 and Open
4462 vSwitch 1.7
4463 NXM: NXM_NX_ND_TLL (25) since Open vSwitch 1.1
4464 ICMPv6 Neighbor Discovery Reserved Field Field
4466 Name: nd_reserved
4469 Width: 32 bits
4470 Format: decimal
4471 Masking: not maskable
4472 Prerequisites: ND
4473 Access: read/write
4474 OpenFlow 1.0: not supported
4475 OpenFlow 1.1: not supported
4477 OXM: none
4478 NXM: ERICOXM_OF_ICMPV6_ND_RESERVED [22m(1) since Open vSwitch
4479 2.11
4480 This is used to set the R,S,O bits in Neighbor Advertisement Messages
4482 ICMPv6 Neighbor Discovery Options Type Field Field
4484 Name: nd_options_type
4486 Width: 8 bits
4487 Format: decimal
4488 Masking: not maskable
4489 Prerequisites: ND
4490 Access: read/write
4491 OpenFlow 1.0: not supported
4493 OpenFlow 1.1: not supported
4494 OXM: none
4495 NXM: ERICOXM_OF_ICMPV6_ND_OPTIONS_TYPE [22m(2) since Open
4496 vSwitch 2.11
4497 A value of 1 indicates that the option is Source Link Layer. A value of
4499 2 indicates that the options is Target Link Layer. See RFC 4861 for
4500 further details.
4501
4503 Casado M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown,
4504 and S. Shenker, ``Ethane: Taking Control of the Enter‐
4505 prise,’’ Computer Communications Review, October 2007.
4506 ERSPAN M. Foschiano, K. Ghosh, M. Mehta, ``Cisco Systems’ Encap‐
4508 sulated Remote Switch Port Analyzer (ERSPAN),’’ ⟨https://
4509 tools.ietf.org/html/draft-foschiano-erspan-03⟩ .
4510 EXT-56 J. Tonsing, ``Permit one of a set of prerequisites to
4512 apply, e.g. don’t preclude non-Ethernet media,’’
4513 ⟨https://rs.opennetworking.org/bugs/browse/EXT-56⟩ (ONF
4514 members only).
4515 EXT-112
4517 J. Tourrilhes, ``Support non-Ethernet packets throughout
4518 the pipeline,’’ ⟨https://rs.opennetworking.org/bugs/
4519 browse/EXT-112⟩ (ONF members only).
4520 EXT-134
4522 J. Tourrilhes, ``Match first nibble of the MPLS pay‐
4523 load,’’ ⟨https://rs.opennetworking.org/bugs/browse/
4524 EXT-134⟩ (ONF members only).
4525 Geneve J. Gross, I. Ganga, and T. Sridhar, editors, ``Geneve:
4527 Generic Network Virtualization Encapsulation,’’ ⟨https://
4528 datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/⟩ .
4529 IEEE OUI
4531 IEEE Standards Association, ``MAC Address Block Large
4532 (MA-L),’’ ⟨https://standards.ieee.org/develop/regauth/
4533 oui/index.html⟩ .
4534 NSH P. Quinn and U. Elzur, editors, ``Network Service
4536 Header,’’ ⟨https://datatracker.ietf.org/doc/
4537 draft-ietf-sfc-nsh/⟩ .
4538 OpenFlow 1.0.1
4540 Open Networking Foundation, ``OpenFlow Switch Errata,
4541 Version 1.0.1,’’ June 2012.
4542 OpenFlow 1.1
4544 OpenFlow Consortium, ``OpenFlow Switch Specification Ver‐
4545 sion 1.1.0 Implemented (Wire Protocol 0x02),’’ February
4546 2011.
4547 OpenFlow 1.5
4549 Open Networking Foundation, ``OpenFlow Switch Specifica‐
4550 tion Version 1.5.0 (Protocol version 0x06),’’ December
4551 2014.
4552 OpenFlow Extensions 1.3.x Package 2
4554 Open Networking Foundation, ``OpenFlow Extensions 1.3.x
4555 Package 2,’’ December 2013.
4556 TCP Flags Match Field Extension
4558 Open Networking Foundation, ``TCP flags match field
4559 Extension,’’ December 2014. In [OpenFlow Extensions 1.3.x
4560 Package 2].
4561 Pepelnjak
4563 I. Pepelnjak, ``OpenFlow and Fermi Estimates,’’ ⟨http://
4564 blog.ipspace.net/2013/09/openflow-and-fermi-esti‐
4565 mates.html⟩ .
4566 RFC 793
4568 ``Transmission Control Protocol,’’ ⟨http://www.ietf.org/
4569 rfc/rfc793.txt⟩ .
4570 RFC 3032
4572 E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Fari‐
4573 nacci, T. Li, and A. Conta, ``MPLS Label Stack Encod‐
4574 ing,’’ ⟨http://www.ietf.org/rfc/rfc3032.txt⟩ .
4575 RFC 3168
4577 K. Ramakrishnan, S. Floyd, and D. Black, ``The Addition
4578 of Explicit Congestion Notification (ECN) to IP,’’
4579 ⟨https://tools.ietf.org/html/rfc3168⟩ .
4580 RFC 3540
4582 N. Spring, D. Wetherall, and D. Ely, ``Robust Explicit
4583 Congestion Notification (ECN) Signaling with Nonces,’’
4584 ⟨https://tools.ietf.org/html/rfc3540⟩ .
4585 RFC 4632
4587 V. Fuller and T. Li, ``Classless Inter-domain Routing
4588 (CIDR): The Internet Address Assignment and Aggregation
4589 Plan,’’ ⟨https://tools.ietf.org/html/rfc4632⟩ .
4590 RFC 5462
4592 L. Andersson and R. Asati, ``Multiprotocol Label Switch‐
4593 ing (MPLS) Label Stack Entry: ``EXP’’ Field Renamed to
4594 ``Traffic Class’’ Field,’’ ⟨http://www.ietf.org/rfc/
4595 rfc5462.txt⟩ .
4596 RFC 6830
4598 D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, ``The
4599 Locator/ID Separation Protocol (LISP),’’ ⟨http://
4600 www.ietf.org/rfc/rfc6830.txt⟩ .
4601 RFC 7348
4603 M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger,
4604 T. Sridhar, M. Bursell, and C. Wright, ``Virtual eXtensi‐
4605 ble Local Area Network (VXLAN): A Framework for Overlay‐
4606 ing Virtualized Layer 2 Networks over Layer 3 Networks,
4607 ’’ ⟨https://tools.ietf.org/html/rfc7348⟩ .
4608 RFC 7665
4610 J. Halpern, Ed. and C. Pignataro, Ed., ``Service Function
4611 Chaining (SFC) Architecture,’’ ⟨https://tools.ietf.org/
4612 html/rfc7665⟩ .
4613 Srinivasan
4615 V. Srinivasan, S. Suriy, and G. Varghese, ``Packet Clas‐
4616 sification using Tuple Space Search,’’ SIGCOMM 1999.
4617 Pagiamtzis
4619 K. Pagiamtzis and A. Sheikholeslami, ``Content-address‐
4620 able memory (CAM) circuits and architectures: A tutorial
4621 and survey,’’ IEEE Journal of Solid-State Circuits, vol.
4622 41, no. 3, pp. 712-727, March 2006.
4623 VXLAN Group Policy Option
4625 M. Smith and L. Kreeger, `` VXLAN Group Policy Option.’’
4626 Internet-Draft. ⟨https://tools.ietf.org/html/
4627 draft-smith-vxlan-group-policy⟩ .
4628
4630 Ben Pfaff, with advice from Justin Pettit and Jean Tourrilhes.
4631Open vSwitch 2.12.0 ovs-fields(7)