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, re‐
11 gardless 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 op‐
40 tions: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 in‐
61 cludes the field’s prerequisite, e.g. matching an ARP field is only al‐
62 lowed 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 ex‐
66 ample, a packet may contain multiple VLAN or MPLS headers, and tunnels
67 can cause any data field to recur. OpenFlow and Open vSwitch do not ad‐
68 dress these cases uniformly. For VLAN and MPLS headers, only the outer‐
69 most header is accessible, so that inner headers may be accessed only
70 by ``popping’’ (removing) the outer header. (Open vSwitch supports only
71 a single VLAN header in any case.) For tunnels, e.g. GRE or VXLAN, the
72 outer header and inner headers are treated as different data fields.
73 Many network protocols are built in layers as a stack of concatenated
75 headers. Each header typically contains a ``next type’’ field that in‐
76 dicates the type of the protocol header that follows, e.g. Ethernet
77 contains an Ethertype and IPv4 contains a IP protocol type. The excep‐
78 tional cases, where protocols are layered but an outer layer does not
79 indicate the protocol type for the inner layer, or gives only an am‐
80 biguous indication, are troublesome. An MPLS header, for example, only
81 indicates whether another MPLS header or some other protocol follows,
82 and in the latter case the inner protocol must be known from the con‐
83 text. In these exceptional cases, OpenFlow and Open vSwitch cannot pro‐
84 vide insight into the inner protocol data fields without additional
85 context, and thus they treat all later data fields as inapplicable un‐
86 til an OpenFlow action explicitly specifies what protocol follows. In
87 the case of MPLS, the OpenFlow ``pop MPLS’’ action that removes the
88 last MPLS header from a packet provides this context, as the Ethertype
89 of the payload. See Layer 2.5: MPLS for more information.
90 OpenFlow and Open vSwitch support some fields other than data fields.
92 Metadata fields relate to the origin or treatment of a packet, but they
93 are not extracted from the packet data itself. One example is the phys‐
94 ical port on which a packet arrived at the switch. Register fields act
95 like variables: they give an OpenFlow switch space for temporary stor‐
96 age while processing a packet. Existing metadata and register fields
97 have no prerequisites.
98 A field’s value consists of an integral number of bytes. For data
100 fields, sometimes those bytes are taken directly from the packet. Other
101 data fields are copied from a packet with padding (usually with zeros
102 and in the most significant positions). The remaining data fields are
103 transformed in other ways as they are copied from the packets, to make
104 them more useful for matching.
105 Matching
107 The most important use of fields in OpenFlow is matching, to determine
108 whether particular field values agree with a set of constraints called
109 a match. A match consists of zero or more constraints on individual
110 fields, all of which must be met to satisfy the match. (A match that
111 contains no constraints is always satisfied.) OpenFlow and Open vSwitch
112 support a number of forms of matching on individual fields:
113 Exact match, e.g. nw_src=10.1.2.3
115 Only a particular value of the field is matched; for ex‐
116 ample, only one particular source IP address. Exact
117 matches are written as field=value. The forms accepted
118 for value depend on the field.
119 All fields support exact matches.
121 Bitwise match, e.g. nw_src=10.1.0.0/255.255.0.0
123 Specific bits in the field must have specified values;
124 for example, only source IP addresses in a particular
125 subnet. Bitwise matches are written as field=value/mask,
126 where value and mask take one of the forms accepted for
127 an exact match on field. Some fields accept other forms
128 for bitwise matches; for example,
129 nw_src=10.1.0.0/255.255.0.0 may also be written
130 nw_src=10.1.0.0/16.
131 Most OpenFlow switches do not allow every bitwise match‐
133 ing on every field (and before OpenFlow 1.2, the protocol
134 did not even provide for the possibility for most
135 fields). Even switches that do allow bitwise matching on
136 a given field may restrict the masks that are allowed,
137 e.g. by allowing matches only on contiguous sets of bits
138 starting from the most significant bit, that is, ``CIDR’’
139 masks [RFC 4632]. Open vSwitch does not allows bitwise
140 matching on every field, but it allows arbitrary bitwise
141 masks on any field that does support bitwise matching.
142 (Older versions had some restrictions, as documented in
143 the descriptions of individual fields.)
144 Wildcard, e.g. ``any nw_src’’
146 The value of the field is not constrained. Wildcarded
147 fields may be written as field=*, although it is unusual
148 to mention them at all. (When specifying a wildcard ex‐
149 plicitly in a command invocation, be sure to using quot‐
150 ing to protect against shell expansion.)
151 There is a tiny difference between wildcarding a field
153 and not specifying any match on a field: wildcarding a
154 field requires satisfying the field’s prerequisites.
155 Some types of matches on individual fields cannot be expressed directly
157 with OpenFlow and Open vSwitch. These can be expressed indirectly:
158 Set match, e.g. ``tcp_dst ∈ {80, 443, 8080}’’
160 The value of a field is one of a specified set of values;
161 for example, the TCP destination port is 80, 443, or
162 8080.
163 For matches used in flows (see Flows, below), multiple
165 flows can simulate set matches.
166 Range match, e.g. ``1000 ≤ tcp_dst ≤ 1999’’
168 The value of the field must lie within a numerical range,
169 for example, TCP destination ports between 1000 and 1999.
170 Range matches can be expressed as a collection of bitwise
172 matches. For example, suppose that the goal is to match
173 TCP source ports 1000 to 1999, inclusive. The binary rep‐
174 resentations of 1000 and 1999 are:
175 01111101000
177 11111001111
178 The following series of bitwise matches will match 1000
181 and 1999 and all the values in between:
182 01111101xxx
184 0111111xxxx
185 10xxxxxxxxx
186 110xxxxxxxx
187 1110xxxxxxx
188 11110xxxxxx
189 1111100xxxx
190 which can be written as the following matches:
193 tcp,tp_src=0x03e8/0xfff8
195 tcp,tp_src=0x03f0/0xfff0
196 tcp,tp_src=0x0400/0xfe00
197 tcp,tp_src=0x0600/0xff00
198 tcp,tp_src=0x0700/0xff80
199 tcp,tp_src=0x0780/0xffc0
200 tcp,tp_src=0x07c0/0xfff0
201 Inequality match, e.g. ``tcp_dst ≠ 80’’
204 The value of the field differs from a specified value,
205 for example, all TCP destination ports except 80.
206 An inequality match on an n-bit field can be expressed as
208 a disjunction of n 1-bit matches. For example, the in‐
209 equality match ``vlan_pcp ≠ 5’’ can be expressed as
210 ``vlan_pcp = 0/4 or vlan_pcp = 2/2 or vlan_pcp = 0/1.’’
211 For matches used in flows (see Flows, below), sometimes
212 one can more compactly express inequality as a higher-
213 priority flow that matches the exceptional case paired
214 with a lower-priority flow that matches the general case.
215 Alternatively, an inequality match may be converted to a
217 pair of range matches, e.g. tcp_src ≠ 80 may be expressed
218 as ``0 ≤ tcp_src < 80 or 80 < tcp_src ≤ 65535’’, and then
219 each range match may in turn be converted to a bitwise
220 match.
221 Conjunctive match, e.g. ``tcp_src ∈ {80, 443, 8080} and tcp_dst
223 ∈ {80, 443, 8080}’’
224 As an OpenFlow extension, Open vSwitch supports matching
225 on conditions on conjunctions of the previously mentioned
226 forms of matching. See the documentation for conj_id for
227 more information.
228 All of these supported forms of matching are special cases of bitwise
230 matching. In some cases this influences the design of field values.
231 ip_frag is the most prominent example: it is designed to make all of
232 the practically useful checks for IP fragmentation possible as a single
233 bitwise match.
234 Shorthands
236 Some matches are very commonly used, so Open vSwitch accepts shorthand
238 notations. In some cases, Open vSwitch also uses shorthand notations
239 when it displays matches. The following shorthands are defined, with
240 their long forms shown on the right side:
241 eth packet_type=(0,0) (Open vSwitch 2.8 and later)
243 ip eth_type=0x0800
245 ipv6 eth_type=0x86dd
247 icmp eth_type=0x0800,ip_proto=1
249 icmp6 eth_type=0x86dd,ip_proto=58
251 tcp eth_type=0x0800,ip_proto=6
253 tcp6 eth_type=0x86dd,ip_proto=6
255 udp eth_type=0x0800,ip_proto=17
257 udp6 eth_type=0x86dd,ip_proto=17
259 sctp eth_type=0x0800,ip_proto=132
261 sctp6 eth_type=0x86dd,ip_proto=132
263 arp eth_type=0x0806
265 rarp eth_type=0x8035
267 mpls eth_type=0x8847
269 mplsm eth_type=0x8848
271 Evolution of OpenFlow Fields
273 The discussion so far applies to all OpenFlow and Open vSwitch ver‐
274 sions. This section starts to draw in specific information by explain‐
275 ing, in broad terms, the treatment of fields and matches in each Open‐
276 Flow version.
277 OpenFlow 1.0
279 OpenFlow 1.0 defined the OpenFlow protocol format of a match as a
281 fixed-length data structure that could match on the following fields:
282 • Ingress port.
284 • Ethernet source and destination MAC.
286 • Ethertype (with a special value to match frames that lack
288 an Ethertype).
289 • VLAN ID and priority.
291 • IPv4 source, destination, protocol, and DSCP.
293 • TCP source and destination port.
295 • UDP source and destination port.
297 • ICMPv4 type and code.
299 • ARP IPv4 addresses (SPA and TPA) and opcode.
301 Each supported field corresponded to some member of the data structure.
303 Some members represented multiple fields, in the case of the TCP, UDP,
304 ICMPv4, and ARP fields whose presence is mutually exclusive. This also
305 meant that some members were poor fits for their fields: only the low 8
306 bits of the 16-bit ARP opcode could be represented, and the ICMPv4 type
307 and code were padded with 8 bits of zeros to fit in the 16-bit members
308 primarily meant for TCP and UDP ports. An additional bitmap member in‐
309 dicated, for each member, whether its field should be an ``exact’’ or
310 ``wildcarded’’ match (see Matching), with additional support for CIDR
311 prefix matching on the IPv4 source and destination fields.
312 Simplicity was recognized early on as the main virtue of this approach.
314 Obviously, any fixed-length data structure cannot support matching new
315 protocols that do not fit. There was no room, for example, for matching
316 IPv6 fields, which was not a priority at the time. Lack of room to sup‐
317 port matching the Ethernet addresses inside ARP packets actually caused
318 more of a design problem later, leading to an Open vSwitch extension
319 action specialized for dropping ``spoofed’’ ARP packets in which the
320 frame and ARP Ethernet source addressed differed. (This extension was
321 never standardized. Open vSwitch dropped support for it a few releases
322 after it added support for full ARP matching.)
323 The design of the OpenFlow fixed-length matches also illustrates com‐
325 promises, in both directions, between the strengths and weaknesses of
326 software and hardware that have always influenced the design of Open‐
327 Flow. Support for matching ARP fields that do fit in the data structure
328 was only added late in the design process (and remained optional in
329 OpenFlow 1.0), for example, because common switch ASICs did not support
330 matching these fields.
331 The compromises in favor of software occurred for more complicated rea‐
333 sons. The OpenFlow designers did not know how to implement matching in
334 software that was fast, dynamic, and general. (A way was later found
335 [Srinivasan].) Thus, the designers sought to support dynamic, general
336 matching that would be fast in realistic special cases, in particular
337 when all of the matches were microflows, that is, matches that specify
338 every field present in a packet, because such matches can be imple‐
339 mented as a single hash table lookup. Contemporary research supported
340 the feasibility of this approach: the number of microflows in a campus
341 network had been measured to peak at about 10,000 [Casado, section
342 3.2]. (Calculations show that this can only be true in a lightly loaded
343 network [Pepelnjak].)
344 As a result, OpenFlow 1.0 required switches to treat microflow matches
346 as the highest possible priority. This let software switches perform
347 the microflow hash table lookup first. Only on failure to match a mi‐
348 croflow did the switch need to fall back to checking the more general
349 and presumed slower matches. Also, the OpenFlow 1.0 flow match was min‐
350 imally flexible, with no support for general bitwise matching, partly
351 on the basis that this seemed more likely amenable to relatively effi‐
352 cient software implementation. (CIDR masking for IPv4 addresses was
353 added relatively late in the OpenFlow 1.0 design process.)
354 Microflow matching was later discovered to aid some hardware implemen‐
356 tations. The TCAM chips used for matching in hardware do not support
357 priority in the same way as OpenFlow but instead tie priority to order‐
358 ing [Pagiamtzis]. Thus, adding a new match with a priority between the
359 priorities of existing matches can require reordering an arbitrary num‐
360 ber of TCAM entries. On the other hand, when microflows are highest
361 priority, they can be managed as a set-aside portion of the TCAM en‐
362 tries.
363 The emphasis on matching microflows also led designers to carefully
365 consider the bandwidth requirements between switch and controller: to
366 maximize the number of microflow setups per second, one must minimize
367 the size of each flow’s description. This favored the fixed-length for‐
368 mat in use, because it expressed common TCP and UDP microflows in fewer
369 bytes than more flexible ``type-length-value’’ (TLV) formats. (Early
370 versions of OpenFlow also avoided TLVs in general to head off protocol
371 fragmentation.)
372 Inapplicable Fields
374 OpenFlow 1.0 does not clearly specify how to treat inapplicable fields.
376 The members for inapplicable fields are always present in the match
377 data structure, as are the bits that indicate whether the fields are
378 matched, and the ``correct’’ member and bit values for inapplicable
379 fields is unclear. OpenFlow 1.0 implementations changed their behavior
380 over time as priorities shifted. The early OpenFlow reference implemen‐
381 tation, motivated to make every flow a microflow to enable hashing,
382 treated inapplicable fields as exact matches on a value of 0. Ini‐
383 tially, this behavior was implemented in the reference controller only.
384 Later, the reference switch was also changed to actually force any
386 wildcarded inapplicable fields into exact matches on 0. The latter be‐
387 havior sometimes caused problems, because the modified flow was the one
388 reported back to the controller later when it queried the flow table,
389 and the modifications sometimes meant that the controller could not
390 properly recognize the flow that it had added. In retrospect, perhaps
391 this problem should have alerted the designers to a design error, but
392 the ability to use a single hash table was held to be more important
393 than almost every other consideration at the time.
394 When more flexible match formats were introduced much later, they dis‐
396 allowed any mention of inapplicable fields as part of a match. This
397 raised the question of how to translate between this new format and the
398 OpenFlow 1.0 fixed format. It seemed somewhat inconsistent and backward
399 to treat fields as exact-match in one format and forbid matching them
400 in the other, so instead the treatment of inapplicable fields in the
401 fixed-length format was changed from exact match on 0 to wildcarding.
402 (A better classifier had by now eliminated software performance prob‐
403 lems with wildcards.)
404 The OpenFlow 1.0.1 errata (released only in 2012) added some additional
406 explanation [OpenFlow 1.0.1, section 3.4], but it did not mandate spe‐
407 cific behavior because of variation among implementations.
408 OpenFlow 1.1
410 The OpenFlow 1.1 protocol match format was designed as a
412 type/length/value (TLV) format to allow for future flexibility. The
413 specification standardized only a single type OFPMT_STANDARD (0) with a
414 fixed-size payload, described here. The additional fields and bitwise
415 masks in OpenFlow 1.1 cause this match structure to be over twice as
416 large as in OpenFlow 1.0, 88 bytes versus 40.
417 OpenFlow 1.1 added support for the following fields:
419 • SCTP source and destination port.
421 • MPLS label and traffic control (TC) fields.
423 • One 64-bit register (named ``metadata’’).
425 OpenFlow 1.1 increased the width of the ingress port number field (and
427 all other port numbers in the protocol) from 16 bits to 32 bits.
428 OpenFlow 1.1 increased matching flexibility by introducing arbitrary
430 bitwise matching on Ethernet and IPv4 address fields and on the new
431 ``metadata’’ register field. Switches were not required to support all
432 possible masks [OpenFlow 1.1, section 4.3].
433 By a strict reading of the specification, OpenFlow 1.1 removed support
435 for matching ICMPv4 type and code [OpenFlow 1.1, section A.2.3], but
436 this is likely an editing error because ICMP matching is described
437 elsewhere [OpenFlow 1.1, Table 3, Table 4, Figure 4]. Open vSwitch does
438 support ICMPv4 type and code matching with OpenFlow 1.1.
439 OpenFlow 1.1 avoided the pitfalls of inapplicable fields that OpenFlow
441 1.0 encountered, by requiring the switch to ignore the specified field
442 values [OpenFlow 1.1, section A.2.3]. It also implied that the switch
443 should ignore the bits that indicate whether to match inapplicable
444 fields.
445 Physical Ingress Port
447 OpenFlow 1.1 introduced a new pseudo-field, the physical ingress port.
449 The physical ingress port is only a pseudo-field because it cannot be
450 used for matching. It appears only one place in the protocol, in the
451 ``packet-in’’ message that passes a packet received at the switch to an
452 OpenFlow controller.
453 A packet’s ingress port and physical ingress port are identical except
455 for packets processed by a switch feature such as bonding or tunneling
456 that makes a packet appear to arrive on a ``virtual’’ port associated
457 with the bond or the tunnel. For such packets, the ingress port is the
458 virtual port and the physical ingress port is, naturally, the physical
459 port. Open vSwitch implements both bonding and tunneling, but its bond‐
460 ing implementation does not use virtual ports and its tunnels are typi‐
461 cally not on the same OpenFlow switch as their physical ingress ports
462 (which need not be part of any switch), so the ingress port and physi‐
463 cal ingress port are always the same in Open vSwitch.
464 OpenFlow 1.2
466 OpenFlow 1.2 abandoned the fixed-length approach to matching. One rea‐
468 son was size, since adding support for IPv6 address matching (now seen
469 as important), with bitwise masks, would have added 64 bytes to the
470 match length, increasing it from 88 bytes in OpenFlow 1.1 to over 150
471 bytes. Extensibility had also become important as controller writers
472 increasingly wanted support for new fields without having to change
473 messages throughout the OpenFlow protocol. The challenges of carefully
474 defining fixed-length matches to avoid problems with inapplicable
475 fields had also become clear over time.
476 Therefore, OpenFlow 1.2 adopted a flow format using a flexible type-
478 length-value (TLV) representation, in which each TLV expresses a match
479 on one field. These TLVs were in turn encapsulated inside the outer TLV
480 wrapper introduced in OpenFlow 1.1 with the new identifier OFPMT_OXM
481 (1). (This wrapper fulfilled its intended purpose of reducing the
482 amount of churn in the protocol when changing match formats; some mes‐
483 sages that included matches remained unchanged from OpenFlow 1.1 to 1.2
484 and later versions.)
485 OpenFlow 1.2 added support for the following fields:
487 • ARP hardware addresses (SHA and THA).
489 • IPv4 ECN.
491 • IPv6 source and destination addresses, flow label, DSCP,
493 ECN, and protocol.
494 • TCP, UDP, and SCTP port numbers when encapsulated inside
496 IPv6.
497 • ICMPv6 type and code.
499 • ICMPv6 Neighbor Discovery target address and source and
501 target Ethernet addresses.
502 The OpenFlow 1.2 format, called OXM (OpenFlow Extensible Match), was
504 modeled closely on an extension to OpenFlow 1.0 introduced in Open
505 vSwitch 1.1 called NXM (Nicira Extended Match). Each OXM or NXM TLV has
506 the following format:
507 type
509 <---------------->
510 16 7 1 8 length bytes
511 +------------+-----+--+------+ +------------+
512 |vendor/class|field|HM|length| | body |
513 +------------+-----+--+------+ +------------+
514 The most significant 16 bits of the NXM or OXM header, called vendor by
517 NXM and class by OXM, identify an organization permitted to allocate
518 identifiers for fields. NXM allocates only two vendors, 0x0000 for
519 fields supported by OpenFlow 1.0 and 0x0001 for fields implemented as
520 an Open vSwitch extension. OXM assigns classes as follows:
521 0x0000 (OFPXMC_NXM_0).
523 0x0001 (OFPXMC_NXM_1).
524 Reserved for NXM compatibility.
525 0x0002 to 0x7fff
527 Reserved for allocation to ONF members, but none yet as‐
528 signed.
529 0x8000 (OFPXMC_OPENFLOW_BASIC)
531 Used for most standard OpenFlow fields.
532 0x8001 (OFPXMC_PACKET_REGS)
534 Used for packet register fields in OpenFlow 1.5 and later.
535 0x8002 to 0xfffe
537 Reserved for the OpenFlow specification.
538 0xffff (OFPXMC_EXPERIMENTER)
540 Experimental use.
541 When class is 0xffff, the OXM header is extended to 64 bits by using
543 the first 32 bits of the body as an experimenter field whose most sig‐
544 nificant byte is zero and whose remaining bytes are an Organizationally
545 Unique Identifier (OUI) assigned by the IEEE [IEEE OUI], as shown be‐
546 low.
547 type experimenter
549 <----------> <---------->
550 16 7 1 8 8 24 (length - 4) bytes
551 +------+-----+--+------+ +------+-----+ +------------------+
552 |class |field|HM|length| | zero | OUI | | body |
553 +------+-----+--+------+ +------+-----+ +------------------+
554 0xffff 0x00
555 OpenFlow says that support for experimenter fields is optional. Open
558 vSwitch 2.4 and later does support them, so that it can support the
559 following experimenter classes:
560 0x4f4e4600 (ONFOXM_ET)
562 Used by official Open Networking Foundation extensions in
563 OpenFlow 1.3 and later. e.g. [TCP Flags Match Field Ex‐
564 tension].
565 0x005ad650 (NXOXM_NSH)
567 Used by Open vSwitch for NSH extensions, in the absence
568 of an official ONF-assigned class. (This OUI is randomly
569 generated.)
570 Taken as a unit, class (or vendor), field, and experimenter (when
572 present) uniquely identify a particular field.
573 When hasmask (abbreviated HM above) is 0, the OXM is an exact match on
575 an entire field. In this case, the body (excluding the experimenter
576 field, if present) is a single value to be matched.
577 When hasmask is 1, the OXM is a bitwise match. The body (excluding the
579 experimenter field) consists of a value to match, followed by the bit‐
580 wise mask to apply. A 1-bit in the mask indicates that the correspond‐
581 ing bit in the value should be matched and a 0-bit that it should be
582 ignored. For example, for an IP address field, a value of 192.168.0.0
583 followed by a mask of 255.255.0.0 would match addresses in the
584 196.168.0.0/16 subnet.
585 • Some fields might not support masking at all, and some
587 fields that do support masking might restrict it to cer‐
588 tain patterns. For example, fields that have IP address
589 values might be restricted to CIDR masks. The descrip‐
590 tions of individual fields note these restrictions.
591 • An OXM TLV with a mask that is all zeros is not useful
593 (although it is not forbidden), because it is has the
594 same effect as omitting the TLV entirely.
595 • It is not meaningful to pair a 0-bit in an OXM mask with
597 a 1-bit in its value, and Open vSwitch rejects such an
598 OXM with the error OFPBMC_BAD_WILDCARDS, as required by
599 OpenFlow 1.3 and later.
600 The length identifies the number of bytes in the body, including the
602 4-byte experimenter header, if it is present. Each OXM TLV has a fixed
603 length; that is, given class, field, experimenter (if present), and
604 hasmask, length is a constant. The length is included explicitly to al‐
605 low software to minimally parse OXM TLVs of unknown types.
606 OXM TLVs must be ordered so that a field’s prerequisites are satisfied
608 before it is parsed. For example, an OXM TLV that matches on the IPv4
609 source address field is only allowed following an OXM TLV that matches
610 on the Ethertype for IPv4. Similarly, an OXM TLV that matches on the
611 TCP source port must follow a TLV that matches an Ethertype of IPv4 or
612 IPv6 and one that matches an IP protocol of TCP (in that order). The
613 order of OXM TLVs is not otherwise restricted; no canonical ordering is
614 defined.
615 A given field may be matched only once in a series of OXM TLVs.
617 OpenFlow 1.3
619 OpenFlow 1.3 showed OXM to be largely successful, by adding new fields
621 without making any changes to how flow matches otherwise worked. It
622 added OXMs for the following fields supported by Open vSwitch:
623 • Tunnel ID for ports associated with e.g. VXLAN or keyed
625 GRE.
626 • MPLS ``bottom of stack’’ (BOS) bit.
628 OpenFlow 1.3 also added OXMs for the following fields not documented
630 here and not yet implemented by Open vSwitch:
631 • IPv6 extension header handling.
633 • PBB I-SID.
635 OpenFlow 1.4
637 OpenFlow 1.4 added OXMs for the following fields not documented here
639 and not yet implemented by Open vSwitch:
640 • PBB UCA.
642 OpenFlow 1.5
644 OpenFlow 1.5 added OXMs for the following fields supported by Open
646 vSwitch:
647 • Packet type.
649 • TCP flags.
651 • Packet registers.
653 • The output port in the OpenFlow action set.
655
657 The following sections document the fields that Open vSwitch supports.
658 Each section provides introductory material on a group of related
659 fields, followed by information on each individual field. In addition
660 to field-specific information, each field begins with a table with en‐
661 tries for the following important properties:
662 Name The field’s name, used for parsing and formatting the
664 field, e.g. in ovs-ofctl commands. For historical rea‐
665 sons, some fields have an additional name that is ac‐
666 cepted as an alternative in parsing. This name, when
667 there is one, is listed as well, e.g. ``tun (aka tun‐
668 nel_id).’’
669 Width The field’s width, always a multiple of 8 bits. Some
671 fields don’t use all of the bits, so this may be accompa‐
672 nied by an explanation. For example, OpenFlow embeds the
673 2-bit IP ECN field as as the low bits in an 8-bit byte,
674 and so its width is expressed as ``8 bits (only the
675 least-significant 2 bits may be nonzero).’’
676 Format How a value for the field is formatted or parsed by,
678 e.g., ovs-ofctl. Some possibilities are generic:
679 decimal
681 Formats as a decimal number. On input, accepts
682 decimal numbers or hexadecimal numbers prefixed by
683 0x.
684 hexadecimal
686 Formats as a hexadecimal number prefixed by 0x. On
687 input, accepts decimal numbers or hexadecimal num‐
688 bers prefixed by 0x. (The default for parsing is
689 not hexadecimal: only a 0x prefix causes input to
690 be treated as hexadecimal.)
691 Ethernet
693 Formats and accepts the common Ethernet address
694 format xx:xx:xx:xx:xx:xx.
695 IPv4 Formats and accepts the dotted-quad format
697 a.b.c.d. For bitwise matches, formats and accepts
698 address/length CIDR notation in addition to ad‐
699 dress/mask.
700 IPv6 Formats and accepts the common IPv6 address for‐
702 mats, plus CIDR notation for bitwise matches.
703 OpenFlow 1.0 port
705 Accepts 16-bit port numbers in decimal, plus Open‐
706 Flow well-known port names (e.g. IN_PORT) in up‐
707 percase or lowercase.
708 OpenFlow 1.1+ port
710 Same syntax as OpenFlow 1.0 ports but for 32-bit
711 OpenFlow 1.1+ port number fields.
712 Other, field-specific formats are explained along with
714 their fields.
715 Masking
717 For most fields, this says ``arbitrary bitwise masks,’’
718 meaning that a flow may match any combination of bits in
719 the field. Some fields instead say ``exact match only,’’
720 which means that a flow that matches on this field must
721 match on the whole field instead of just certain bits.
722 Either way, this reports masking support for the latest
723 version of Open vSwitch using OXM or NXM (that is, either
724 OpenFlow 1.2+ or OpenFlow 1.0 plus Open vSwitch NXM ex‐
725 tensions). In particular, OpenFlow 1.0 (without NXM) and
726 1.1 don’t always support masking even if Open vSwitch it‐
727 self does; refer to the OpenFlow 1.0 and OpenFlow 1.1
728 rows to learn about masking with these protocol versions.
729 Prerequisites
731 Requirements that must be met to match on this field. For
732 example, ip_src has IPv4 as a prerequisite, meaning that
733 a match must include eth_type=0x0800 to match on the IPv4
734 source address. The following prerequisites, with their
735 requirements, are currently in use:
736 none (no requirements)
738 VLAN VID
740 vlan_tci=0x1000/0x1000 (i.e. a VLAN header is
741 present)
742 ARP eth_type=0x0806 (ARP) or eth_type=0x8035 (RARP)
744 IPv4 eth_type=0x0800
746 IPv6 eth_type=0x86dd
748 IPv4/IPv6
750 IPv4 or IPv6
751 MPLS eth_type=0x8847 or eth_type=0x8848
753 TCP IPv4/IPv6 and ip_proto=6
755 UDP IPv4/IPv6 and ip_proto=17
757 SCTP IPv4/IPv6 and ip_proto=132
759 ICMPv4 IPv4 and ip_proto=1
761 ICMPv6 IPv6 and ip_proto=58
763 ND solicit
765 ICMPv6 and icmp_type=135 and icmp_code=0
766 ND advert
768 ICMPv6 and icmp_type=136 and icmp_code=0
769 ND ND solicit or ND advert
771 The TCP, UDP, and SCTP prerequisites also have the spe‐
773 cial requirement that nw_frag is not being used to select
774 ``later fragments.’’ This is because only the first frag‐
775 ment of a fragmented IPv4 or IPv6 datagram contains the
776 TCP or UDP header.
777 Access Most fields are ``read/write,’’ which means that common
779 OpenFlow actions like set_field can modify them. Fields
780 that are ``read-only’’ cannot be modified in these gen‐
781 eral-purpose ways, although there may be other ways that
782 actions can modify them.
783 OpenFlow 1.0
785 OpenFlow 1.1
786 These rows report the level of support that OpenFlow 1.0 or
787 OpenFlow 1.1, respectively, has for a field. For OpenFlow
788 1.0, supported fields are reported as either ``yes (exact
789 match only)’’ for fields that do not support any bitwise
790 masking or ``yes (CIDR match only)’’ for fields that sup‐
791 port CIDR masking. OpenFlow 1.1 supported fields report ei‐
792 ther ``yes (exact match only)’’ or simply ``yes’’ for
793 fields that do support arbitrary masks. These OpenFlow ver‐
794 sions supported a fixed collection of fields that cannot be
795 extended, so many more fields are reported as ``not sup‐
796 ported.’’
797 OXM
799 NXM These rows report the OXM and NXM code points that corre‐
800 spond to a given field. Either or both may be ``none.’’
801 A field that has only an OXM code point is usually one that
803 was standardized before it was added to Open vSwitch. A
804 field that has only an NXM code point is usually one that
805 is not yet standardized. When a field has both OXM and NXM
806 code points, it usually indicates that it was introduced as
807 an Open vSwitch extension under the NXM code point, then
808 later standardized under the OXM code point. A field can
809 have more than one OXM code point if it was standardized in
810 OpenFlow 1.4 or later and additionally introduced as an of‐
811 ficial ONF extension for OpenFlow 1.3. (A field that has
812 neither OXM nor NXM code point is typically an obsolete
813 field that is supported in some other form using OXM or
814 NXM.)
815 Each code point in these rows is described in the form
817 ``NAME (number) since OpenFlow spec and Open vSwitch ver‐
818 sion,’’ e.g. ``OXM_OF_ETH_TYPE (5) since OpenFlow 1.2 and
819 Open vSwitch 1.7.’’ First, NAME, which specifies a name for
820 the code point, starts with a prefix that designates a
821 class and, in some cases, a vendor, as listed in the fol‐
822 lowing table:
823 Prefix Vendor Class
825 ─────────────── ─────────── ───────
826 NXM_OF (none) 0x0000
827 NXM_NX (none) 0x0001
828 ERICOXM_OF (none) 0x1000
829 OXM_OF (none) 0x8000
830 OXM_OF_PKT_REG (none) 0x8001
831 NXOXM_ET 0x00002320 0xffff
832 NXOXM_NSH 0x005ad650 0xffff
833 ONFOXM_ET 0x4f4e4600 0xffff
834 For more information on OXM/NXM classes and vendors, refer
836 back to OpenFlow 1.2 under Evolution of OpenFlow Fields.
837 The number is the field number within the class and vendor.
838 The OpenFlow spec is the version of OpenFlow that standard‐
839 ized the code point. It is omitted for NXM code points be‐
840 cause they are nonstandard. The version is the version of
841 Open vSwitch that first supported the code point.
842
844 Summary:
845 Name Bytes Mask RW? Prereqs NXM/OXM Support
846 ──────── ────── ───── ──── ──────── ────────────────
847 conj_id 4 no no none OVS 2.4+
848 An individual OpenFlow flow can match only a single value for each
850 field. However, situations often arise where one wants to match one of
851 a set of values within a field or fields. For matching a single field
852 against a set, it is straightforward and efficient to add multiple
853 flows to the flow table, one for each value in the set. For example,
854 one might use the following flows to send packets with IP source ad‐
855 dress a, b, c, or d to the OpenFlow controller:
856 ip,ip_src=a actions=controller
858 ip,ip_src=b actions=controller
859 ip,ip_src=c actions=controller
860 ip,ip_src=d actions=controller
861 Similarly, these flows send packets with IP destination address e, f,
864 g, or h to the OpenFlow controller:
865 ip,ip_dst=e actions=controller
867 ip,ip_dst=f actions=controller
868 ip,ip_dst=g actions=controller
869 ip,ip_dst=h actions=controller
870 Installing all of the above flows in a single flow table yields a dis‐
873 junctive effect: a packet is sent to the controller if ip_src ∈
874 {a,b,c,d} or ip_dst ∈ {e,f,g,h} (or both). (Pedantically, if both of
875 the above sets of flows are present in the flow table, they should have
876 different priorities, because OpenFlow says that the results are unde‐
877 fined when two flows with same priority can both match a single
878 packet.)
879 Suppose, on the other hand, one wishes to match conjunctively, that is,
881 to send a packet to the controller only if both ip_src ∈ {a,b,c,d} and
882 ip_dst ∈ {e,f,g,h}. This requires 4 × 4 = 16 flows, one for each possi‐
883 ble pairing of ip_src and ip_dst. That is acceptable for our small ex‐
884 ample, but it does not gracefully extend to larger sets or greater num‐
885 bers of dimensions.
886 The conjunction action is a solution for conjunctive matches that is
888 built into Open vSwitch. A conjunction action ties groups of individual
889 OpenFlow flows into higher-level ``conjunctive flows’’. Each group cor‐
890 responds to one dimension, and each flow within the group matches one
891 possible value for the dimension. A packet that matches one flow from
892 each group matches the conjunctive flow.
893 To implement a conjunctive flow with conjunction, assign the conjunc‐
895 tive flow a 32-bit id, which must be unique within an OpenFlow table.
896 Assign each of the n ≥ 2 dimensions a unique number from 1 to n; the
897 ordering is unimportant. Add one flow to the OpenFlow flow table for
898 each possible value of each dimension with conjunction(id, k/n) as the
899 flow’s actions, where k is the number assigned to the flow’s dimension.
900 Together, these flows specify the conjunctive flow’s match condition.
901 When the conjunctive match condition is met, Open vSwitch looks up one
902 more flow that specifies the conjunctive flow’s actions and receives
903 its statistics. This flow is found by setting conj_id to the specified
904 id and then again searching the flow table.
905 The following flows provide an example. Whenever the IP source is one
907 of the values in the flows that match on the IP source (dimension 1 of
908 2), and the IP destination is one of the values in the flows that match
909 on IP destination (dimension 2 of 2), Open vSwitch searches for a flow
910 that matches conj_id against the conjunction ID (1234), finding the
911 first flow listed below.
912 conj_id=1234 actions=controller
914 ip,ip_src=10.0.0.1 actions=conjunction(1234, 1/2)
915 ip,ip_src=10.0.0.4 actions=conjunction(1234, 1/2)
916 ip,ip_src=10.0.0.6 actions=conjunction(1234, 1/2)
917 ip,ip_src=10.0.0.7 actions=conjunction(1234, 1/2)
918 ip,ip_dst=10.0.0.2 actions=conjunction(1234, 2/2)
919 ip,ip_dst=10.0.0.5 actions=conjunction(1234, 2/2)
920 ip,ip_dst=10.0.0.7 actions=conjunction(1234, 2/2)
921 ip,ip_dst=10.0.0.8 actions=conjunction(1234, 2/2)
922 Many subtleties exist:
925 • In the example above, every flow in a single dimension
927 has the same form, that is, dimension 1 matches on ip_src
928 and dimension 2 on ip_dst, but this is not a requirement.
929 Different flows within a dimension may match on different
930 bits within a field (e.g. IP network prefixes of differ‐
931 ent lengths, or TCP/UDP port ranges as bitwise matches),
932 or even on entirely different fields (e.g. to match pack‐
933 ets for TCP source port 80 or TCP destination port 80).
934 • The flows within a dimension can vary their matches
936 across more than one field, e.g. to match only specific
937 pairs of IP source and destination addresses or L4 port
938 numbers.
939 • A flow may have multiple conjunction actions, with dif‐
941 ferent id values. This is useful for multiple conjunctive
942 flows with overlapping sets. If one conjunctive flow
943 matches packets with both ip_src ∈ {a,b} and ip_dst ∈
944 {d,e} and a second conjunctive flow matches ip_src ∈
945 {b,c} and ip_dst ∈ {f,g}, for example, then the flow that
946 matches ip_src=b would have two conjunction actions, one
947 for each conjunctive flow. The order of conjunction ac‐
948 tions within a list of actions is not significant.
949 • A flow with conjunction actions may also include note ac‐
951 tions for annotations, but not any other kind of actions.
952 (They would not be useful because they would never be ex‐
953 ecuted.)
954 • All of the flows that constitute a conjunctive flow with
956 a given id must have the same priority. (Flows with the
957 same id but different priorities are currently treated as
958 different conjunctive flows, that is, currently id values
959 need only be unique within an OpenFlow table at a given
960 priority. This behavior isn’t guaranteed to stay the same
961 in later releases, so please use id values unique within
962 an OpenFlow table.)
963 • Conjunctive flows must not overlap with each other, at a
965 given priority, that is, any given packet must be able to
966 match at most one conjunctive flow at a given priority.
967 Overlapping conjunctive flows yield unpredictable re‐
968 sults. (The flows that constitute a conjunctive flow may
969 overlap with those that constitute the same or another
970 conjunctive flow.)
971 • Following a conjunctive flow match, the search for the
973 flow with conj_id=id is done in the same general-purpose
974 way as other flow table searches, so one can use flows
975 with conj_id=id to act differently depending on circum‐
976 stances. (One exception is that the search for the
977 conj_id=id flow itself ignores conjunctive flows, to
978 avoid recursion.) If the search with conj_id=id fails,
979 Open vSwitch acts as if the conjunctive flow had not
980 matched at all, and continues searching the flow table
981 for other matching flows.
982 • OpenFlow prerequisite checking occurs for the flow with
984 conj_id=id in the same way as any other flow, e.g. in an
985 OpenFlow 1.1+ context, putting a mod_nw_src action into
986 the example above would require adding an ip match, like
987 this:
988 conj_id=1234,ip actions=mod_nw_src:1.2.3.4,controller
990 • OpenFlow prerequisite checking also occurs for the indi‐
993 vidual flows that comprise a conjunctive match in the
994 same way as any other flow.
995 • The flows that constitute a conjunctive flow do not have
997 useful statistics. They are never updated with byte or
998 packet counts, and so on. (For such a flow, therefore,
999 the idle and hard timeouts work much the same way.)
1000 • Sometimes there is a choice of which flows include a par‐
1002 ticular match. For example, suppose that we added an ex‐
1003 tra constraint to our example, to match on ip_src ∈
1004 {a,b,c,d} and ip_dst ∈ {e,f,g,h} and tcp_dst = i. One way
1005 to implement this is to add the new constraint to the
1006 conj_id flow, like this:
1007 conj_id=1234,tcp,tcp_dst=i actions=mod_nw_src:1.2.3.4,controller
1009 but this is not recommended because of the cost of the
1012 extra flow table lookup. Instead, add the constraint to
1013 the individual flows, either in one of the dimensions or
1014 (slightly better) all of them.
1015 • A conjunctive match must have n ≥ 2 dimensions (otherwise
1017 a conjunctive match is not necessary). Open vSwitch en‐
1018 forces this.
1019 • Each dimension within a conjunctive match should ordinar‐
1021 ily have more than one flow. Open vSwitch does not en‐
1022 force this.
1023 Conjunction ID Field
1025 Name: conj_id
1027 Width: 32 bits
1028 Format: decimal
1029 Masking: not maskable
1030 Prerequisites: none
1031 Access: read-only
1032 OpenFlow 1.0: not supported
1033 OpenFlow 1.1: not supported
1034 OXM: none
1036 NXM: NXM_NX_CONJ_ID (37) since Open vSwitch 2.4
1037 Used for conjunctive matching. See above for more information.
1039
1041 Summary:
1042 Name Bytes Mask RW? Prereqs NXM/OXM Support
1043 ───────────────────── ──────────────── ───── ──── ──────── ─────────────────────
1045 tun_id aka tunnel_id 8 yes yes none OF 1.3+ and OVS 1.1+
1046 tun_src 4 yes yes none OVS 2.0+
1047 tun_dst 4 yes yes none OVS 2.0+
1048 tun_ipv6_src 16 yes yes none OVS 2.5+
1050 tun_ipv6_dst 16 yes yes none OVS 2.5+
1051 tun_gbp_id 2 yes yes none OVS 2.4+
1052 tun_gbp_flags 1 yes yes none OVS 2.4+
1053 tun_erspan_ver 1 (low 4 bits) yes yes none OVS 2.10+
1055 tun_erspan_idx 4 (low 20 bits) yes yes none OVS 2.10+
1056 tun_erspan_dir 1 (low 1 bits) yes yes none OVS 2.10+
1057 tun_erspan_hwid 1 (low 6 bits) yes yes none OVS 2.10+
1058 tun_gtpu_flags 1 yes no none OVS 2.13+
1060 tun_gtpu_msgtype 1 yes no none OVS 2.13+
1061 tun_metadata0 124 yes yes none OVS 2.5+
1062 tun_metadata1 124 yes yes none OVS 2.5+
1063 tun_metadata2 124 yes yes none OVS 2.5+
1065 tun_metadata3 124 yes yes none OVS 2.5+
1066 tun_metadata4 124 yes yes none OVS 2.5+
1067 tun_metadata5 124 yes yes none OVS 2.5+
1068 tun_metadata6 124 yes yes none OVS 2.5+
1070 tun_metadata7 124 yes yes none OVS 2.5+
1071 tun_metadata8 124 yes yes none OVS 2.5+
1072 tun_metadata9 124 yes yes none OVS 2.5+
1073 tun_metadata10 124 yes yes none OVS 2.5+
1075 tun_metadata11 124 yes yes none OVS 2.5+
1076 tun_metadata12 124 yes yes none OVS 2.5+
1077 tun_metadata13 124 yes yes none OVS 2.5+
1078 tun_metadata14 124 yes yes none OVS 2.5+
1080 tun_metadata15 124 yes yes none OVS 2.5+
1081 tun_metadata16 124 yes yes none OVS 2.5+
1082 tun_metadata17 124 yes yes none OVS 2.5+
1083 tun_metadata18 124 yes yes none OVS 2.5+
1085 tun_metadata19 124 yes yes none OVS 2.5+
1086 tun_metadata20 124 yes yes none OVS 2.5+
1087 tun_metadata21 124 yes yes none OVS 2.5+
1088 tun_metadata22 124 yes yes none OVS 2.5+
1090 tun_metadata23 124 yes yes none OVS 2.5+
1091 tun_metadata24 124 yes yes none OVS 2.5+
1092 tun_metadata25 124 yes yes none OVS 2.5+
1093 tun_metadata26 124 yes yes none OVS 2.5+
1095 tun_metadata27 124 yes yes none OVS 2.5+
1096 tun_metadata28 124 yes yes none OVS 2.5+
1097 tun_metadata29 124 yes yes none OVS 2.5+
1098 tun_metadata30 124 yes yes none OVS 2.5+
1100 tun_metadata31 124 yes yes none OVS 2.5+
1101 tun_metadata32 124 yes yes none OVS 2.5+
1102 tun_metadata33 124 yes yes none OVS 2.5+
1103 tun_metadata34 124 yes yes none OVS 2.5+
1105 tun_metadata35 124 yes yes none OVS 2.5+
1106 tun_metadata36 124 yes yes none OVS 2.5+
1107 tun_metadata37 124 yes yes none OVS 2.5+
1108 tun_metadata38 124 yes yes none OVS 2.5+
1110 tun_metadata39 124 yes yes none OVS 2.5+
1111 tun_metadata40 124 yes yes none OVS 2.5+
1112 tun_metadata41 124 yes yes none OVS 2.5+
1113 tun_metadata42 124 yes yes none OVS 2.5+
1115 tun_metadata43 124 yes yes none OVS 2.5+
1116 tun_metadata44 124 yes yes none OVS 2.5+
1117 tun_metadata45 124 yes yes none OVS 2.5+
1118 tun_metadata46 124 yes yes none OVS 2.5+
1120 tun_metadata47 124 yes yes none OVS 2.5+
1121 tun_metadata48 124 yes yes none OVS 2.5+
1122 tun_metadata49 124 yes yes none OVS 2.5+
1123 tun_metadata50 124 yes yes none OVS 2.5+
1125 tun_metadata51 124 yes yes none OVS 2.5+
1126 tun_metadata52 124 yes yes none OVS 2.5+
1127 tun_metadata53 124 yes yes none OVS 2.5+
1128 tun_metadata54 124 yes yes none OVS 2.5+
1130 tun_metadata55 124 yes yes none OVS 2.5+
1131 tun_metadata56 124 yes yes none OVS 2.5+
1132 tun_metadata57 124 yes yes none OVS 2.5+
1133 tun_metadata58 124 yes yes none OVS 2.5+
1135 tun_metadata59 124 yes yes none OVS 2.5+
1136 tun_metadata60 124 yes yes none OVS 2.5+
1137 tun_metadata61 124 yes yes none OVS 2.5+
1138 tun_metadata62 124 yes yes none OVS 2.5+
1140 tun_metadata63 124 yes yes none OVS 2.5+
1141 tun_flags 2 (low 1 bits) yes yes none OVS 2.5+
1142 The fields in this group relate to tunnels, which Open vSwitch supports
1144 in several forms (GRE, VXLAN, and so on). Most of these fields do ap‐
1145 pear in the wire format of a packet, so they are data fields from that
1146 point of view, but they are metadata from an OpenFlow flow table point
1147 of view because they do not appear in packets that are forwarded to the
1148 controller or to ordinary (non-tunnel) output ports.
1149 Open vSwitch supports a spectrum of usage models for mapping tunnels to
1151 OpenFlow ports:
1152 ``Port-based’’ tunnels
1154 In this model, an OpenFlow port represents one tunnel: it
1155 matches a particular type of tunnel traffic between two
1156 IP endpoints, with a particular tunnel key (if keys are
1157 in use). In this situation, in_port suffices to distin‐
1158 guish one tunnel from another, so the tunnel header
1159 fields have little importance for OpenFlow processing.
1160 (They are still populated and may be used if it is conve‐
1161 nient.) The tunnel header fields play no role in sending
1162 packets out such an OpenFlow port, either, because the
1163 OpenFlow port itself fully specifies the tunnel headers.
1164 The following Open vSwitch commands create a bridge
1166 br-int, add port tap0 to the bridge as OpenFlow port 1,
1167 establish a port-based GRE tunnel between the local host
1168 and remote IP 192.168.1.1 using GRE key 5001 as OpenFlow
1169 port 2, and arranges to forward all traffic from tap0 to
1170 the tunnel and vice versa:
1171 ovs-vsctl add-br br-int
1173 ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1174 ovs-vsctl add-port br-int gre0 -- \
1175 set interface gre0 ofport_request=2 type=gre \
1176 options:remote_ip=192.168.1.1 options:key=5001
1177 ovs-ofctl add-flow br-int in_port=1,actions=2
1178 ovs-ofctl add-flow br-int in_port=2,actions=1
1179 ``Flow-based’’ tunnels
1182 In this model, one OpenFlow port represents all possible
1183 tunnels of a given type with an endpoint on the current
1184 host, for example, all GRE tunnels. In this situation,
1185 in_port only indicates that traffic was received on the
1186 particular kind of tunnel. This is where the tunnel
1187 header fields are most important: they allow the OpenFlow
1188 tables to discriminate among tunnels based on their IP
1189 endpoints or keys. Tunnel header fields also determine
1190 the IP endpoints and keys of packets sent out such a tun‐
1191 nel port.
1192 The following Open vSwitch commands create a bridge
1194 br-int, add port tap0 to the bridge as OpenFlow port 1,
1195 establish a flow-based GRE tunnel port 3, and arranges to
1196 forward all traffic from tap0 to remote IP 192.168.1.1
1197 over a GRE tunnel with key 5001 and vice versa:
1198 ovs-vsctl add-br br-int
1200 ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1201 ovs-vsctl add-port br-int allgre -- \
1202 set interface allgre ofport_request=3 type=gre \
1203 options:remote_ip=flow options:key=flow
1204 ovs-ofctl add-flow br-int \
1205 ’in_port=1 actions=set_tunnel:5001,set_field:192.168.1.1->tun_dst,3’
1206 ovs-ofctl add-flow br-int ’in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1’
1207 Mixed models.
1210 One may define both flow-based and port-based tunnels at
1211 the same time. For example, it is valid and possibly use‐
1212 ful to create and configure both gre0 and allgre tunnel
1213 ports described above.
1214 Traffic is attributed on ingress to the most specific
1216 matching tunnel. For example, gre0 is more specific than
1217 allgre. Therefore, if both exist, then gre0 will be the
1218 ingress port for any GRE traffic received from
1219 192.168.1.1 with key 5001.
1220 On egress, traffic may be directed to any appropriate
1222 tunnel port. If both gre0 and allgre are configured as
1223 already described, then the actions 2 and set_tun‐
1224 nel:5001,set_field:192.168.1.1->tun_dst,3 send the same
1225 tunnel traffic.
1226 Intermediate models.
1228 Ports may be configured as partially flow-based. For ex‐
1229 ample, one may define an OpenFlow port that represents
1230 tunnels between a pair of endpoints but leaves the flow
1231 table to discriminate on the flow key.
1232 ovs-vswitchd.conf.db(5) describes all the details of tunnel configura‐
1234 tion.
1235 These fields do not have any prerequisites, which means that a flow may
1237 match on any or all of them, in any combination.
1238 These fields are zeros for packets that did not arrive on a tunnel.
1240 Tunnel ID Field
1242 Name: tun_id (aka tunnel_id)
1244 Width: 64 bits
1245 Format: hexadecimal
1246 Masking: arbitrary bitwise masks
1248 Prerequisites: none
1249 Access: read/write
1250 OpenFlow 1.0: not supported
1251 OpenFlow 1.1: not supported
1252 OXM: OXM_OF_TUNNEL_ID (38) since OpenFlow 1.3 and Open
1255 vSwitch 1.10
1256 NXM: NXM_NX_TUN_ID (16) since Open vSwitch 1.1
1257 Many kinds of tunnels support a tunnel ID:
1259 • VXLAN and Geneve have a 24-bit virtual network identifier
1261 (VNI).
1262 • LISP has a 24-bit instance ID.
1264 • GRE has an optional 32-bit key.
1266 • STT has a 64-bit key.
1268 • ERSPAN has a 10-bit key (Session ID).
1270 • GTPU has a 32-bit key (Tunnel Endpoint ID).
1272 When a packet is received from a tunnel, this field holds the tunnel ID
1274 in its least significant bits, zero-extended to fit. This field is zero
1275 if the tunnel does not support an ID, or if no ID is in use for a tun‐
1276 nel type that has an optional ID, or if an ID of zero received, or if
1277 the packet was not received over a tunnel.
1278 When a packet is output to a tunnel port, the tunnel configuration de‐
1280 termines whether the tunnel ID is taken from this field or bound to a
1281 fixed value. See the earlier description of ``port-based’’ and ``flow-
1282 based’’ tunnels for more information.
1283 The following diagram shows the origin of this field in a typical keyed
1285 GRE tunnel:
1286 Ethernet IPv4 GRE Ethernet
1288 <-----------> <---------------> <------------> <---------->
1289 48 48 16 8 32 32 16 16 32 48 48 16
1290 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1291 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1292 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1293 0x800 47 0x6558
1294 Tunnel IPv4 Source Field
1297 Name: tun_src
1299 Width: 32 bits
1300 Format: IPv4
1301 Masking: arbitrary bitwise masks
1302 Prerequisites: none
1303 Access: read/write
1304 OpenFlow 1.0: not supported
1305 OpenFlow 1.1: not supported
1306 OXM: none
1308 NXM: NXM_NX_TUN_IPV4_SRC (31) since Open vSwitch 2.0
1309 When a packet is received from a tunnel, this field is the source ad‐
1311 dress in the outer IP header of the tunneled packet. This field is zero
1312 if the packet was not received over a tunnel.
1313 When a packet is output to a flow-based tunnel port, this field influ‐
1315 ences the IPv4 source address used to send the packet. If it is zero,
1316 then the kernel chooses an appropriate IP address based using the rout‐
1317 ing table.
1318 The following diagram shows the origin of this field in a typical keyed
1320 GRE tunnel:
1321 Ethernet IPv4 GRE Ethernet
1323 <-----------> <---------------> <------------> <---------->
1324 48 48 16 8 32 32 16 16 32 48 48 16
1325 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1326 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1327 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1328 0x800 47 0x6558
1329 Tunnel IPv4 Destination Field
1332 Name: tun_dst
1335 Width: 32 bits
1336 Format: IPv4
1337 Masking: arbitrary bitwise masks
1338 Prerequisites: none
1339 Access: read/write
1340 OpenFlow 1.0: not supported
1341 OpenFlow 1.1: not supported
1342 OXM: none
1344 NXM: NXM_NX_TUN_IPV4_DST (32) since Open vSwitch 2.0
1345 When a packet is received from a tunnel, this field is the destination
1347 address in the outer IP header of the tunneled packet. This field is
1348 zero if the packet was not received over a tunnel.
1349 When a packet is output to a flow-based tunnel port, this field speci‐
1351 fies the destination to which the tunnel packet is sent.
1352 The following diagram shows the origin of this field in a typical keyed
1354 GRE tunnel:
1355 Ethernet IPv4 GRE Ethernet
1357 <-----------> <---------------> <------------> <---------->
1358 48 48 16 8 32 32 16 16 32 48 48 16
1359 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1360 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1361 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1362 0x800 47 0x6558
1363 Tunnel IPv6 Source Field
1366 Name: tun_ipv6_src
1368 Width: 128 bits
1369 Format: IPv6
1371 Masking: arbitrary bitwise masks
1372 Prerequisites: none
1373 Access: read/write
1374 OpenFlow 1.0: not supported
1375 OpenFlow 1.1: not supported
1376 OXM: none
1377 NXM: NXM_NX_TUN_IPV6_SRC (109) since Open vSwitch 2.5
1378 Similar to tun_src, but for tunnels over IPv6.
1380 Tunnel IPv6 Destination Field
1382 Name: tun_ipv6_dst
1384 Width: 128 bits
1385 Format: IPv6
1386 Masking: arbitrary bitwise masks
1387 Prerequisites: none
1389 Access: read/write
1390 OpenFlow 1.0: not supported
1391 OpenFlow 1.1: not supported
1392 OXM: none
1393 NXM: NXM_NX_TUN_IPV6_DST (110) since Open vSwitch 2.5
1394 Similar to tun_dst, but for tunnels over IPv6.
1396 VXLAN Group-Based Policy Fields
1398 The VXLAN header is defined as follows [RFC 7348], where the I bit must
1399 be set to 1, unlabeled bits or those labeled reserved must be set to 0,
1400 and Open vSwitch makes the VNI available via tun_id:
1401 VXLAN flags
1403 <------------->
1404 1 1 1 1 1 1 1 1 24 24 8
1405 +-+-+-+-+-+-+-+-+--------+---+--------+
1406 | | | | |I| | | |reserved|VNI|reserved|
1407 +-+-+-+-+-+-+-+-+--------+---+--------+
1408 VXLAN Group-Based Policy [VXLAN Group Policy Option] adds new interpre‐
1411 tations to existing bits in the VXLAN header, reinterpreting it as fol‐
1412 lows, with changes highlighted:
1413 GBP flags
1415 <------------->
1416 1 1 1 1 1 1 1 1 24 24 8
1417 +-+-+-+-+-+-+-+-+---------------+---+--------+
1418 | |D| | |A| | | |group policy ID|VNI|reserved|
1419 +-+-+-+-+-+-+-+-+---------------+---+--------+
1420 Open vSwitch makes GBP fields and flags available through the following
1423 fields. Only packets that arrive over a VXLAN tunnel with the GBP ex‐
1424 tension enabled have these fields set. In other packets they are zero
1425 on receive and ignored on transmit.
1426 VXLAN Group-Based Policy ID Field
1428 Name: tun_gbp_id
1430 Width: 16 bits
1431 Format: decimal
1432 Masking: arbitrary bitwise masks
1434 Prerequisites: none
1435 Access: read/write
1436 OpenFlow 1.0: not supported
1437 OpenFlow 1.1: not supported
1438 OXM: none
1439 NXM: NXM_NX_TUN_GBP_ID (38) since Open vSwitch 2.4
1440 For a packet tunneled over VXLAN with the Group-Based Policy (GBP) ex‐
1442 tension, this field represents the GBP policy ID, as shown above.
1443 VXLAN Group-Based Policy Flags Field
1445 Name: tun_gbp_flags
1447 Width: 8 bits
1448 Format: hexadecimal
1449 Masking: arbitrary bitwise masks
1450 Prerequisites: none
1452 Access: read/write
1453 OpenFlow 1.0: not supported
1454 OpenFlow 1.1: not supported
1455 OXM: none
1456 NXM: NXM_NX_TUN_GBP_FLAGS (39) since Open vSwitch 2.4
1457 For a packet tunneled over VXLAN with the Group-Based Policy (GBP) ex‐
1459 tension, this field represents the GBP policy flags, as shown above.
1460 The field has the format shown below:
1462 GBP Flags
1464 <------------->
1465 1 1 1 1 1 1 1 1
1466 +-+-+-+-+-+-+-+-+
1467 | |D| | |A| | | |
1468 +-+-+-+-+-+-+-+-+
1469 Unlabeled bits are reserved and must be transmitted as 0. The VXLAN GBP
1472 draft defines the other bits’ meanings as:
1473 D (Don’t Learn)
1475 When set, this bit indicates that the egress tunnel end‐
1476 point must not learn the source address of the encapsu‐
1477 lated frame.
1478 A (Applied)
1480 When set, indicates that the group policy has already
1481 been applied to this packet. Devices must not apply poli‐
1482 cies when the A bit is set.
1483 ERSPAN Metadata Fields
1485 These fields provide access to features in the ERSPAN tunneling proto‐
1486 col [ERSPAN], which has two major versions: version 1 (aka type II) and
1487 version 2 (aka type III).
1488 Regardless of version, ERSPAN is encapsulated within a fixed 8-byte GRE
1490 header that consists of a 4-byte GRE base header and a 4-byte sequence
1491 number. The ERSPAN version 1 header format is:
1492 GRE ERSPAN v1 Ethernet
1494 <------------> <---------------------> <---------->
1495 16 16 32 4 18 10 12 20 48 48 16
1496 +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1497 |...| type |seq| |ver|...|session|...|idx| |dst|src|type| ...
1498 +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1499 0x88be 1 tun_id
1500 The ERSPAN version 2 header format is:
1503 GRE ERSPAN v2 Ethernet
1505 <------------> <----------------------------------------> <---------->
1506 16 16 32 4 18 10 32 22 6 1 3 48 48 16
1507 +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1508 |...| type |seq| |ver|...|session|timestamp|...|hwid|dir|...| |dst|src|type| ...
1509 +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1510 0x22eb 2 tun_id 0/1
1511 ERSPAN Version Field
1514 Name: tun_erspan_ver
1516 Width: 8 bits (only the least-significant 4 bits may be nonzero)
1517 Format: decimal
1518 Masking: arbitrary bitwise masks
1519 Prerequisites: none
1520 Access: read/write
1521 OpenFlow 1.0: not supported
1522 OpenFlow 1.1: not supported
1524 OXM: none
1525 NXM: NXOXM_ET_ERSPAN_VER (12) since Open vSwitch 2.10
1526 ERSPAN version number: 1 for version 1, or 2 for version 2.
1528 ERSPAN Index Field
1530 Name: tun_erspan_idx
1533 Width: 32 bits (only the least-significant 20 bits may be nonzero)
1534 Format: hexadecimal
1535 Masking: arbitrary bitwise masks
1536 Prerequisites: none
1537 Access: read/write
1538 OpenFlow 1.0: not supported
1539 OpenFlow 1.1: not supported
1540 OXM: none
1542 NXM: NXOXM_ET_ERSPAN_IDX (11) since Open vSwitch 2.10
1543 This field is a 20-bit index/port number associated with the ERSPAN
1545 traffic’s source port and direction (ingress/egress). This field is
1546 platform dependent.
1547 ERSPAN Direction Field
1549 Name: tun_erspan_dir
1551 Width: 8 bits (only the least-significant 1 bits may be nonzero)
1552 Format: decimal
1553 Masking: arbitrary bitwise masks
1554 Prerequisites: none
1555 Access: read/write
1556 OpenFlow 1.0: not supported
1557 OpenFlow 1.1: not supported
1558 OXM: none
1560 NXM: NXOXM_ET_ERSPAN_DIR (13) since Open vSwitch 2.10
1561 For ERSPAN v2, the mirrored traffic’s direction: 0 for ingress traffic,
1563 1 for egress traffic.
1564 ERSPAN Hardware ID Field
1566 Name: tun_erspan_hwid
1569 Width: 8 bits (only the least-significant 6 bits may be nonzero)
1570 Format: hexadecimal
1571 Masking: arbitrary bitwise masks
1572 Prerequisites: none
1573 Access: read/write
1574 OpenFlow 1.0: not supported
1575 OpenFlow 1.1: not supported
1576 OXM: none
1578 NXM: NXOXM_ET_ERSPAN_HWID (14) since Open vSwitch 2.10
1579 A 6-bit unique identifier of an ERSPAN v2 engine within a system.
1581 GTP-U Metadata Fields
1583 These fields provide access to set-up GPRS Tunnelling Protocol for User
1584 Plane (GTPv1-U), based on 3GPP TS 29.281. A GTP-U header has the fol‐
1585 lowing format:
1586 8 8 16 32
1588 +-----+--------+------+----+
1589 |flags|msg type|length|TEID| ...
1590 +-----+--------+------+----+
1591 The flags and message type have the Open vSwitch GTP-U specific fields
1594 described below. Open vSwitch makes the TEID (Tunnel Endpoint Identi‐
1595 fier), which identifies a tunnel endpoint in the receiving GTP-U proto‐
1596 col entity, available via tun_id.
1597 GTP-U Flags Field
1599 Name: tun_gtpu_flags
1601 Width: 8 bits
1602 Format: hexadecimal
1603 Masking: arbitrary bitwise masks
1605 Prerequisites: none
1606 Access: read-only
1607 OpenFlow 1.0: not supported
1608 OpenFlow 1.1: not supported
1609 OXM: none
1610 NXM: NXOXM_ET_GTPU_FLAGS (15) since Open vSwitch 2.13
1611 This field holds the 8-bit GTP-U flags, encoded as:
1613 GTP-U Tunnel Flags
1615 <------------------->
1616 3 1 1 1 1 1
1617 +-------+--+---+-+-+--+
1618 |version|PT|rsv|E|S|PN|
1619 +-------+--+---+-+-+--+
1620 1 0
1621 The flags are:
1624 version
1626 Used to determine the version of the GTP-U protocol,
1627 which should be set to 1.
1628 PT Protocol type, used as a protocol discriminator between
1630 GTP (1) and GTP’ (0).
1631 rsv Reserved. Must be zero.
1633 E If 1, indicates the presence of a meaningful value of the
1635 Next Extension Header field.
1636 S If 1, indicates the presence of a meaningful value of the
1638 Sequence Number field.
1639 PN If 1, indicates the presence of a meaningful value of the
1641 N-PDU Number field.
1642 GTP-U Message Type Field
1644 Name: tun_gtpu_msgtype
1646 Width: 8 bits
1647 Format: decimal
1648 Masking: arbitrary bitwise masks
1650 Prerequisites: none
1651 Access: read-only
1652 OpenFlow 1.0: not supported
1653 OpenFlow 1.1: not supported
1654 OXM: none
1655 NXM: NXOXM_ET_GTPU_MSGTYPE (16) since Open vSwitch 2.13
1656 This field indicates whether it’s a signalling message used for path
1658 management, or a user plane message which carries the original packet.
1659 The complete range of message types can be referred to [3GPP TS
1660 29.281].
1661 Geneve Fields
1663 These fields provide access to additional features in the Geneve tun‐
1664 neling protocol [Geneve]. Their names are somewhat generic in the hope
1665 that the same fields could be reused for other protocols in the future;
1666 for example, the NSH protocol [NSH] supports TLV options whose form is
1667 identical to that for Geneve options.
1668 Generic Tunnel Option 0 Field
1670 Name: tun_metadata0
1672 Width: 992 bits (124 bytes)
1673 Format: hexadecimal
1674 Masking: arbitrary bitwise masks
1675 Prerequisites: none
1677 Access: read/write
1678 OpenFlow 1.0: not supported
1679 OpenFlow 1.1: not supported
1680 OXM: none
1681 NXM: NXM_NX_TUN_METADATA0 (40) since Open vSwitch 2.5
1682 The above information specifically covers generic tunnel option 0, but
1684 Open vSwitch supports 64 options, numbered 0 through 63, whose NXM
1685 field numbers are 40 through 103.
1686 These fields provide OpenFlow access to the generic type-length-value
1688 options defined by the Geneve tunneling protocol or other protocols
1689 with options in the same TLV format as Geneve options. Each of these
1690 options has the following wire format:
1691 header body
1693 <-------------------> <------------------>
1694 16 8 3 5 4×(length - 1) bytes
1695 +-----+----+---+------+--------------------+
1696 |class|type|res|length| value |
1697 +-----+----+---+------+--------------------+
1698 0
1699 Taken together, the class and type in the option format mean that there
1702 are about 16 million distinct kinds of TLV options, too many to give
1703 individual OXM code points. Thus, Open vSwitch requires the user to de‐
1704 fine the TLV options of interest, by binding up to 64 TLV options to
1705 generic tunnel option NXM code points. Each option may have up to 124
1706 bytes in its body, the maximum allowed by the TLV format, but bound op‐
1707 tions may total at most 252 bytes of body.
1708 Open vSwitch extensions to the OpenFlow protocol bind TLV options to
1710 NXM code points. The ovs-ofctl(8) program offers one way to use these
1711 extensions, e.g. to configure a mapping from a TLV option with class
1712 0xffff, type 0, and a body length of 4 bytes:
1713 ovs-ofctl add-tlv-map br0 "{class=0xffff,type=0,len=4}->tun_metadata0"
1715 Once a TLV option is properly bound, it can be accessed and modified
1718 like any other field, e.g. to send packets that have value 1234 for the
1719 option described above to the controller:
1720 ovs-ofctl add-flow br0 tun_metadata0=1234,actions=controller
1722 An option not received or not bound is matched as all zeros.
1725 Tunnel Flags Field
1727 Name: tun_flags
1729 Width: 16 bits (only the least-significant 1 bits may be nonzero)
1731 Format: tunnel flags
1732 Masking: arbitrary bitwise masks
1733 Prerequisites: none
1734 Access: read/write
1735 OpenFlow 1.0: not supported
1736 OpenFlow 1.1: not supported
1737 OXM: none
1738 NXM: NXM_NX_TUN_FLAGS (104) since Open vSwitch 2.5
1740 Flags indicating various aspects of the tunnel encapsulation.
1742 Matches on this field are most conveniently written in terms of sym‐
1744 bolic names (given in the diagram below), each preceded by either + for
1745 a flag that must be set, or - for a flag that must be unset, without
1746 any other delimiters between the flags. Flags not mentioned are wild‐
1747 carded. For example, tun_flags=+oam matches only OAM packets. Matches
1748 can also be written as flags/mask, where flags and mask are 16-bit num‐
1749 bers in decimal or in hexadecimal prefixed by 0x.
1750 Currently, only one flag is defined:
1752 oam The tunnel protocol indicated that this is an OAM (Opera‐
1754 tions and Management) control packet.
1755 The switch may reject matches against unknown flags.
1757 Newer versions of Open vSwitch may introduce additional flags with new
1759 meanings. It is therefore not recommended to use an exact match on this
1760 field since the behavior of these new flags is unknown and should be
1761 ignored.
1762 For non-tunneled packets, the value is 0.
1764
1766 Summary:
1767 Name Bytes Mask RW? Prereqs NXM/OXM Support
1768 ────────────── ────── ───── ──── ──────── ─────────────────────
1769 in_port 2 no yes none OVS 1.1+
1770 in_port_oxm 4 no yes none OF 1.2+ and OVS 1.7+
1772 skb_priority 4 no no none
1773 pkt_mark 4 yes yes none OVS 2.0+
1774 actset_output 4 no no none OF 1.3+ and OVS 2.4+
1775 packet_type 4 no no none OF 1.5+ and OVS 2.8+
1776 These fields relate to the origin or treatment of a packet, but they
1778 are not extracted from the packet data itself.
1779 Ingress Port Field
1781 Name: in_port
1783 Width: 16 bits
1784 Format: OpenFlow 1.0 port
1786 Masking: not maskable
1787 Prerequisites: none
1788 Access: read/write
1789 OpenFlow 1.0: yes (exact match only)
1790 OpenFlow 1.1: yes (exact match only)
1791 OXM: none
1793 NXM: NXM_OF_IN_PORT (0) since Open vSwitch 1.1
1794 The OpenFlow port on which the packet being processed arrived. This is
1796 a 16-bit field that holds an OpenFlow 1.0 port number. For receiving a
1797 packet, the only values that appear in this field are:
1798 1 through 0xfeff (65,279), inclusive.
1800 Conventional OpenFlow port numbers.
1801 OFPP_LOCAL (0xfffe or 65,534).
1803 The ``local’’ port, which in Open vSwitch is always named
1804 the same as the bridge itself. This represents a connec‐
1805 tion between the switch and the local TCP/IP stack. This
1806 port is where an IP address is most commonly configured
1807 on an Open vSwitch switch.
1808 OpenFlow does not require a switch to have a local port,
1810 but all existing versions of Open vSwitch have always in‐
1811 cluded a local port. Future Directions: Future versions
1812 of Open vSwitch might be able to optionally omit the lo‐
1813 cal port, if someone submits code to implement such a
1814 feature.
1815 OFPP_NONE (OpenFlow 1.0) or OFPP_ANY (OpenFlow 1.1+) (0xffff or
1817 65,535).
1818 OFPP_CONTROLLER (0xfffd or 65,533).
1819 When a controller injects a packet into an OpenFlow switch
1820 with a ``packet-out’’ request, it can specify one of these
1821 ingress ports to indicate that the packet was generated in‐
1822 ternally rather than having been received on some port.
1823 OpenFlow 1.0 specified OFPP_NONE for this purpose. Despite
1825 that, some controllers used OFPP_CONTROLLER, and some
1826 switches only accepted OFPP_CONTROLLER, so OpenFlow 1.0.2
1827 required support for both ports. OpenFlow 1.1 and later
1828 were more clearly drafted to allow only OFPP_CONTROLLER.
1829 For maximum compatibility, Open vSwitch allows both ports
1830 with all OpenFlow versions.
1831 Values not mentioned above will never appear when receiving a packet,
1833 including the following notable values:
1834 0 Zero is not a valid OpenFlow port number.
1836 OFPP_MAX (0xff00 or 65,280).
1838 This value has only been clearly specified as a valid
1839 port number as of OpenFlow 1.3.3. Before that, its status
1840 was unclear, and so Open vSwitch has never allowed
1841 OFPP_MAX to be used as a port number, so packets will
1842 never be received on this port. (Other OpenFlow switches,
1843 of course, might use it.)
1844 OFPP_UNSET (0xfff7 or 65,527)
1846 OFPP_IN_PORT (0xfff8 or 65,528)
1847 OFPP_TABLE (0xfff9 or 65,529)
1848 OFPP_NORMAL (0xfffa or 65,530)
1849 OFPP_FLOOD (0xfffb or 65,531)
1850 OFPP_ALL (0xfffc or 65,532)
1851 These port numbers are used only in output actions and
1852 never appear as ingress ports.
1853 Most of these port numbers were defined in OpenFlow 1.0,
1855 but OFPP_UNSET was only introduced in OpenFlow 1.5.
1856 Values that will never appear when receiving a packet may still be
1858 matched against in the flow table. There are still circumstances in
1859 which those flows can be matched:
1860 • The resubmit Open vSwitch extension action allows a flow
1862 table lookup with an arbitrary ingress port.
1863 • An action that modifies the ingress port field (see be‐
1865 low), such as e.g. load or set_field, followed by an ac‐
1866 tion or instruction that performs another flow table
1867 lookup, such as resubmit or goto_table.
1868 This field is heavily used for matching in OpenFlow tables, but for
1870 packet egress, it has only very limited roles:
1871 • OpenFlow requires suppressing output actions to in_port.
1873 That is, the following two flows both drop all packets
1874 that arrive on port 1:
1875 in_port=1,actions=1
1877 in_port=1,actions=drop
1878 (This behavior is occasionally useful for flooding to a
1881 subset of ports. Specifying actions=1,2,3,4, for example,
1882 outputs to ports 1, 2, 3, and 4, omitting the ingress
1883 port.)
1884 • OpenFlow has a special port OFPP_IN_PORT (with value
1886 0xfff8) that outputs to the ingress port. For example, in
1887 a switch that has four ports numbered 1 through 4, ac‐
1888 tions=1,2,3,4,in_port outputs to ports 1, 2, 3, and 4,
1889 including the ingress port.
1890 Because the ingress port field has so little influence on packet pro‐
1892 cessing, it does not ordinarily make sense to modify the ingress port
1893 field. The field is writable only to support the occasional use case
1894 where the ingress port’s roles in packet egress, described above, be‐
1895 come troublesome. For example, actions=load:0->NXM_OF_IN_PORT[],out‐
1896 put:123 will output to port 123 regardless of whether it is in the
1897 ingress port. If the ingress port is important, then one may save and
1898 restore it on the stack:
1899 actions=push:NXM_OF_IN_PORT[],load:0->NXM_OF_IN_PORT[],output:123,pop:NXM_OF_IN_PORT[]
1901 or, in Open vSwitch 2.7 or later, use the clone action to save and re‐
1904 store it:
1905 actions=clone(load:0->NXM_OF_IN_PORT[],output:123)
1907 The ability to modify the ingress port is an Open vSwitch extension to
1910 OpenFlow.
1911 OXM Ingress Port Field
1913 Name: in_port_oxm
1915 Width: 32 bits
1916 Format: OpenFlow 1.1+ port
1917 Masking: not maskable
1918 Prerequisites: none
1919 Access: read/write
1920 OpenFlow 1.0: not supported
1921 OpenFlow 1.1: yes (exact match only)
1922 OXM: OXM_OF_IN_PORT (0) since OpenFlow 1.2 and Open vSwitch
1924 1.7
1925 NXM: none
1926 OpenFlow 1.1 and later use a 32-bit port number, so this field supplies
1928 a 32-bit view of the ingress port. Current versions of Open vSwitch
1929 support only a 16-bit range of ports:
1930 • OpenFlow 1.0 ports 0x0000 to 0xfeff, inclusive, map to
1932 OpenFlow 1.1 port numbers with the same values.
1933 • OpenFlow 1.0 ports 0xff00 to 0xffff, inclusive, map to
1935 OpenFlow 1.1 port numbers 0xffffff00 to 0xffffffff.
1936 • OpenFlow 1.1 ports 0x0000ff00 to 0xfffffeff are not
1938 mapped and not supported.
1939 in_port and in_port_oxm are two views of the same information, so all
1941 of the comments on in_port apply to in_port_oxm too. Modifying in_port
1942 changes in_port_oxm, and vice versa.
1943 Setting in_port_oxm to an unsupported value yields unspecified behav‐
1945 ior.
1946 Output Queue Field
1948 Name: skb_priority
1950 Width: 32 bits
1951 Format: hexadecimal
1952 Masking: not maskable
1954 Prerequisites: none
1955 Access: read-only
1956 OpenFlow 1.0: not supported
1957 OpenFlow 1.1: not supported
1958 OXM: none
1959 NXM: none
1960 Future Directions: Open vSwitch implements the output queue as a field,
1962 but does not currently expose it through OXM or NXM for matching pur‐
1963 poses. If this turns out to be a useful feature, it could be imple‐
1964 mented in future versions. Only the set_queue, enqueue, and pop_queue
1965 actions currently influence the output queue.
1966 This field influences how packets in the flow will be queued, for qual‐
1968 ity of service (QoS) purposes, when they egress the switch. Its range
1969 of meaningful values, and their meanings, varies greatly from one Open‐
1970 Flow implementation to another. Even within a single implementation,
1971 there is no guarantee that all OpenFlow ports have the same queues con‐
1972 figured or that all OpenFlow ports in an implementation can be config‐
1973 ured the same way queue-wise.
1974 Configuring queues on OpenFlow is not well standardized. On Linux, Open
1976 vSwitch supports queue configuration via OVSDB, specifically the QoS
1977 and Queue tables (see ovs-vswitchd.conf.db(5) for details). Ports of
1978 Open vSwitch to other platforms might require queue configuration
1979 through some separate protocol (such as a CLI). Even on Linux, Open
1980 vSwitch exposes only a fraction of the kernel’s queuing features
1981 through OVSDB, so advanced or unusual uses might require use of sepa‐
1982 rate utilities (e.g. tc). OpenFlow switches other than Open vSwitch
1983 might use OF-CONFIG or any of the configuration methods mentioned
1984 above. Finally, some OpenFlow switches have a fixed number of fixed-
1985 function queues (e.g. eight queues with strictly defined priorities)
1986 and others do not support any control over queuing.
1987 The only output queue that all OpenFlow implementations must support is
1989 zero, to identify a default queue, whose properties are implementation-
1990 defined. Outputting a packet to a queue that does not exist on the out‐
1991 put port yields unpredictable behavior: among the possibilities are
1992 that the packet might be dropped or transmitted with a very high or
1993 very low priority.
1994 OpenFlow 1.0 only allowed output queues to be specified as part of an
1996 enqueue action that specified both a queue and an output port. That is,
1997 OpenFlow 1.0 treats the queue as an argument to an action, not as a
1998 field.
1999 To increase flexibility, OpenFlow 1.1 added an action to set the output
2001 queue. This model was carried forward, without change, through OpenFlow
2002 1.5.
2003 Open vSwitch implements the native queuing model of each OpenFlow ver‐
2005 sion it supports. Open vSwitch also includes an extension for setting
2006 the output queue as an action in OpenFlow 1.0.
2007 When a packet ingresses into an OpenFlow switch, the output queue is
2009 ordinarily set to 0, indicating the default queue. However, Open
2010 vSwitch supports various ways to forward a packet from one OpenFlow
2011 switch to another within a single host. In these cases, Open vSwitch
2012 maintains the output queue across the forwarding step. For example:
2013 • A hop across an Open vSwitch ``patch port’’ (which does
2015 not actually involve queuing) preserves the output queue.
2016 • When a flow sets the output queue then outputs to an
2018 OpenFlow tunnel port, the encapsulation preserves the
2019 output queue. If the kernel TCP/IP stack routes the en‐
2020 capsulated packet directly to a physical interface, then
2021 that output honors the output queue. Alternatively, if
2022 the kernel routes the encapsulated packet to another Open
2023 vSwitch bridge, then the output queue set previously be‐
2024 comes the initial output queue on ingress to the second
2025 bridge and will thus be used for further output actions
2026 (unless overridden by a new ``set queue’’ action).
2027 (This description reflects the current behavior of Open
2029 vSwitch on Linux. This behavior relies on details of the
2030 Linux TCP/IP stack. It could be difficult to make ports
2031 to other operating systems behave the same way.)
2032 Packet Mark Field
2034 Name: pkt_mark
2036 Width: 32 bits
2037 Format: hexadecimal
2038 Masking: arbitrary bitwise masks
2039 Prerequisites: none
2040 Access: read/write
2041 OpenFlow 1.0: not supported
2042 OpenFlow 1.1: not supported
2044 OXM: none
2045 NXM: NXM_NX_PKT_MARK (33) since Open vSwitch 2.0
2046 Packet mark comes to Open vSwitch from the Linux kernel, in which the
2048 sk_buff data structure that represents a packet contains a 32-bit mem‐
2049 ber named skb_mark. The value of skb_mark propagates along with the
2050 packet it accompanies wherever the packet goes in the kernel. It has no
2051 predefined semantics but various kernel-user interfaces can set and
2052 match on it, which makes it suitable for ``marking’’ packets at one
2053 point in their handling and then acting on the mark later. With ipta‐
2054 bles, for example, one can mark some traffic specially at ingress and
2055 then handle that traffic differently at egress based on the marked
2056 value.
2057 Packet mark is an attempt at a generalization of the skb_mark concept
2059 beyond Linux, at least through more generic naming. Like skb_priority,
2060 packet mark is preserved across forwarding steps within a machine. Un‐
2061 like skb_priority, packet mark has no direct effect on packet forward‐
2062 ing: the value set in packet mark does not matter unless some later
2063 OpenFlow table or switch matches on packet mark, or unless the packet
2064 passes through some other kernel subsystem that has been configured to
2065 interpret packet mark in specific ways, e.g. through iptables configu‐
2066 ration mentioned above.
2067 Preserving packet mark across kernel forwarding steps relies heavily on
2069 kernel support, which ports to non-Linux operating systems may not
2070 have. Regardless of operating system support, Open vSwitch supports
2071 packet mark within a single bridge and across patch ports.
2072 The value of packet mark when a packet ingresses into the first Open
2074 vSwich bridge is typically zero, but it could be nonzero if its value
2075 was previously set by some kernel subsystem.
2076 Action Set Output Port Field
2078 Name: actset_output
2080 Width: 32 bits
2081 Format: OpenFlow 1.1+ port
2082 Masking: not maskable
2084 Prerequisites: none
2085 Access: read-only
2086 OpenFlow 1.0: not supported
2087 OpenFlow 1.1: not supported
2088 OXM: ONFOXM_ET_ACTSET_OUTPUT (43) since OpenFlow 1.3 and
2089 Open vSwitch 2.4; OXM_OF_ACTSET_OUTPUT [22m(43) since
2090 OpenFlow 1.5 and Open vSwitch 2.4
2091 NXM: none
2092 Holds the output port currently in the OpenFlow action set (i.e. from
2094 an output action within a write_actions instruction). Its value is an
2095 OpenFlow port number. If there is no output port in the OpenFlow action
2096 set, or if the output port will be ignored (e.g. because there is an
2097 output group in the OpenFlow action set), then the value will be
2098 OFPP_UNSET.
2099 Open vSwitch allows any table to match this field. OpenFlow, however,
2101 only requires this field to be matchable from within an OpenFlow egress
2102 table (a feature that Open vSwitch does not yet implement).
2103 Packet Type Field
2105 Name: packet_type
2107 Width: 32 bits
2108 Format: packet type
2109 Masking: not maskable
2110 Prerequisites: none
2111 Access: read-only
2112 OpenFlow 1.0: not supported
2114 OpenFlow 1.1: not supported
2115 OXM: OXM_OF_PACKET_TYPE [22m(44) since OpenFlow 1.5 and Open
2116 vSwitch 2.8
2117 NXM: none
2118 The type of the packet in the format specified in OpenFlow 1.5:
2120 Packet type
2122 <--------->
2123 16 16
2124 +---+-------+
2125 |ns |ns_type| ...
2126 +---+-------+
2127 The upper 16 bits, ns, are a namespace. The meaning of ns_type depends
2130 on the namespace. The packet type field is specified and displayed in
2131 the format (ns,ns_type).
2132 Open vSwitch currently supports the following classes of packet types
2134 for matching:
2135 (0,0) Ethernet.
2137 (1,ethertype)
2139 The specified ethertype. Open vSwitch can forward packets
2140 with any ethertype, but it can only match on and process
2141 data fields for the following supported packet types:
2142 (1,0x800)
2144 IPv4
2145 (1,0x806)
2147 ARP
2148 (1,0x86dd)
2150 IPv6
2151 (1,0x8847)
2153 MPLS
2154 (1,0x8848)
2156 MPLS multicast
2157 (1,0x8035)
2159 RARP
2160 (1,0x894f)
2162 NSH
2163 Consider the distinction between a packet with packet_type=(0,0),
2165 dl_type=0x800 and one with packet_type=(1,0x800). The former is an Eth‐
2166 ernet frame that contains an IPv4 packet, like this:
2167 Ethernet IPv4
2169 <-----------> <--------------->
2170 48 48 16 8 32 32
2171 +---+---+-----+ +---+-----+---+---+
2172 |dst|src|type | |...|proto|src|dst| ...
2173 +---+---+-----+ +---+-----+---+---+
2174 0x800
2175 The latter is an IPv4 packet not encapsulated inside any outer frame,
2178 like this:
2179 IPv4
2181 <--------------->
2182 8 32 32
2183 +---+-----+---+---+
2184 |...|proto|src|dst| ...
2185 +---+-----+---+---+
2186 Matching on packet_type is a pre-requisite for matching on any data
2189 field, but for backward compatibility, when a match on a data field is
2190 present without a packet_type match, Open vSwitch acts as though a
2191 match on (0,0) (Ethernet) had been supplied. Similarly, when Open
2192 vSwitch sends flow match information to a controller, e.g. in a reply
2193 to a request to dump the flow table, Open vSwitch omits a match on
2194 packet type (0,0) if it would be implied by a data field match.
2195
2197 Summary:
2198 Name Bytes Mask RW? Prereqs NXM/OXM Support
2199 ──────────── ────── ───── ──── ──────── ────────────────
2201 ct_state 4 yes no none OVS 2.5+
2202 ct_zone 2 no no none OVS 2.5+
2203 ct_mark 4 yes yes none OVS 2.5+
2204 ct_label 16 yes yes none OVS 2.5+
2206 ct_nw_src 4 yes no CT OVS 2.8+
2207 ct_nw_dst 4 yes no CT OVS 2.8+
2208 ct_ipv6_src 16 yes no CT OVS 2.8+
2209 ct_ipv6_dst 16 yes no CT OVS 2.8+
2211 ct_nw_proto 1 no no CT OVS 2.8+
2212 ct_tp_src 2 yes no CT OVS 2.8+
2213 ct_tp_dst 2 yes no CT OVS 2.8+
2214 Open vSwitch supports ``connection tracking,’’ which allows bidirec‐
2216 tional streams of packets to be statefully grouped into connections.
2217 Open vSwitch connection tracking, for example, identifies the patterns
2218 of TCP packets that indicates a successfully initiated connection, as
2219 well as those that indicate that a connection has been torn down. Open
2220 vSwitch connection tracking can also identify related connections, such
2221 as FTP data connections spawned from FTP control connections.
2222 An individual packet passing through the pipeline may be in one of two
2224 states, ``untracked’’ or ``tracked,’’ which may be distinguished via
2225 the ``trk’’ flag in ct_state. A packet is untracked at the beginning of
2226 the Open vSwitch pipeline and continues to be untracked until the pipe‐
2227 line invokes the ct action. The connection tracking fields are all ze‐
2228 roes in an untracked packet. When a flow in the Open vSwitch pipeline
2229 invokes the ct action, the action initializes the connection tracking
2230 fields and the packet becomes tracked for the remainder of its process‐
2231 ing.
2232 The connection tracker stores connection state in an internal table,
2234 but it only adds a new entry to this table when a ct action for a new
2235 connection invokes ct with the commit parameter. For a given connec‐
2236 tion, when a pipeline has executed ct, but not yet with commit, the
2237 connection is said to be uncommitted. State for an uncommitted connec‐
2238 tion is ephemeral and does not persist past the end of the pipeline, so
2239 some features are only available to committed connections. A connection
2240 would typically be left uncommitted as a way to drop its packets.
2241 Connection tracking is an Open vSwitch extension to OpenFlow. Open
2243 vSwitch 2.5 added the initial support for connection tracking. Subse‐
2244 quent versions of Open vSwitch added many refinements and extensions to
2245 the initial support. Many of these capabilities depend on the Open
2246 vSwitch datapath rather than simply the userspace version. The capabil‐
2247 ities column in the Datapath table (see ovs-vswitchd.conf.db(5)) re‐
2248 ports the detailed capabilities of a particular Open vSwitch datapath.
2249 Connection Tracking State Field
2251 Name: ct_state
2253 Width: 32 bits
2254 Format: ct state
2256 Masking: arbitrary bitwise masks
2257 Prerequisites: none
2258 Access: read-only
2259 OpenFlow 1.0: not supported
2261 OpenFlow 1.1: not supported
2262 OXM: none
2263 NXM: NXM_NX_CT_STATE (105) since Open vSwitch 2.5
2264 This field holds several flags that can be used to determine the state
2266 of the connection to which the packet belongs.
2267 Matches on this field are most conveniently written in terms of sym‐
2269 bolic names (listed below), each preceded by either + for a flag that
2270 must be set, or - for a flag that must be unset, without any other de‐
2271 limiters between the flags. Flags not mentioned are wildcarded. For ex‐
2272 ample, tcp,ct_state=+trk-new matches TCP packets that have been run
2273 through the connection tracker and do not establish a new connection.
2274 Matches can also be written as flags/mask, where flags and mask are
2275 32-bit numbers in decimal or in hexadecimal prefixed by 0x.
2276 The following flags are defined:
2278 new (0x01)
2280 A new connection. Set to 1 if this is an uncommitted con‐
2281 nection.
2282 est (0x02)
2284 Part of an existing connection. Set to 1 if packets of a
2285 committed connection have been seen by conntrack from
2286 both directions.
2287 rel (0x04)
2289 Related to an existing connection, e.g. an ICMP ``desti‐
2290 nation unreachable’’ message or an FTP data connections.
2291 This flag will only be 1 if the connection to which this
2292 one is related is committed.
2293 Connections identified as rel are separate from the orig‐
2295 inating connection and must be committed separately. All
2296 packets for a related connection will have the rel flag
2297 set, not just the initial packet.
2298 rpl (0x08)
2300 This packet is in the reply direction, meaning that it is
2301 in the opposite direction from the packet that initiated
2302 the connection. This flag will only be 1 if the connec‐
2303 tion is committed.
2304 inv (0x10)
2306 The state is invalid, meaning that the connection tracker
2307 couldn’t identify the connection. This flag is a catch-
2308 all for problems in the connection or the connection
2309 tracker, such as:
2310 • L3/L4 protocol handler is not loaded/unavailable.
2312 With the Linux kernel datapath, this may mean that
2313 the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules
2314 are not loaded.
2315 • L3/L4 protocol handler determines that the packet
2317 is malformed.
2318 • Packets are unexpected length for protocol.
2320 trk (0x20)
2322 This packet is tracked, meaning that it has previously
2323 traversed the connection tracker. If this flag is not
2324 set, then no other flags will be set. If this flag is
2325 set, then the packet is tracked and other flags may also
2326 be set.
2327 snat (0x40)
2329 This packet was transformed by source address/port trans‐
2330 lation by a preceding ct action. Open vSwitch 2.6 added
2331 this flag.
2332 dnat (0x80)
2334 This packet was transformed by destination address/port
2335 translation by a preceding ct action. Open vSwitch 2.6
2336 added this flag.
2337 There are additional constraints on these flags, listed in decreasing
2339 order of precedence below:
2340 1. If trk is unset, no other flags are set.
2342 2. If trk is set, one or more other flags may be set.
2344 3. If inv is set, only the trk flag is also set.
2346 4. new and est are mutually exclusive.
2348 5. new and rpl are mutually exclusive.
2350 6. rel may be set in conjunction with any other flags.
2352 Future versions of Open vSwitch may define new flags.
2354 Connection Tracking Zone Field
2356 Name: ct_zone
2358 Width: 16 bits
2359 Format: hexadecimal
2360 Masking: not maskable
2361 Prerequisites: none
2363 Access: read-only
2364 OpenFlow 1.0: not supported
2365 OpenFlow 1.1: not supported
2366 OXM: none
2367 NXM: NXM_NX_CT_ZONE (106) since Open vSwitch 2.5
2368 A connection tracking zone, the zone value passed to the most recent ct
2370 action. Each zone is an independent connection tracking context, so
2371 tracking the same packet in multiple contexts requires using the ct ac‐
2372 tion multiple times.
2373 Connection Tracking Mark Field
2375 Name: ct_mark
2377 Width: 32 bits
2378 Format: hexadecimal
2379 Masking: arbitrary bitwise masks
2380 Prerequisites: none
2381 Access: read/write
2382 OpenFlow 1.0: not supported
2383 OpenFlow 1.1: not supported
2384 OXM: none
2385 NXM: NXM_NX_CT_MARK (107) since Open vSwitch 2.5
2386 The metadata committed, by an action within the exec parameter to the
2388 ct action, to the connection to which the current packet belongs.
2389 Connection Tracking Label Field
2391 Name: ct_label
2393 Width: 128 bits
2394 Format: hexadecimal
2395 Masking: arbitrary bitwise masks
2396 Prerequisites: none
2397 Access: read/write
2398 OpenFlow 1.0: not supported
2399 OpenFlow 1.1: not supported
2400 OXM: none
2402 NXM: NXM_NX_CT_LABEL (108) since Open vSwitch 2.5
2403 The label committed, by an action within the exec parameter to the ct
2405 action, to the connection to which the current packet belongs.
2406 Open vSwitch 2.8 introduced the matching support for connection tracker
2408 original direction 5-tuple fields.
2409 For non-committed non-related connections the conntrack original direc‐
2411 tion tuple fields always have the same values as the corresponding
2412 headers in the packet itself. For any other packets of a committed con‐
2413 nection the conntrack original direction tuple fields reflect the val‐
2414 ues from that initial non-committed non-related packet, and thus may be
2415 different from the actual packet headers, as the actual packet headers
2416 may be in reverse direction (for reply packets), transformed by NAT
2417 (when nat option was applied to the connection), or be of different
2418 protocol (i.e., when an ICMP response is sent to an UDP packet). In
2419 case of related connections, e.g., an FTP data connection, the original
2420 direction tuple contains the original direction headers from the parent
2421 connection, e.g., an FTP control connection.
2422 The following fields are populated by the ct action, and require a
2424 match to a valid connection tracking state as a prerequisite, in addi‐
2425 tion to the IP or IPv6 ethertype match. Examples of valid connection
2426 tracking state matches include ct_state=+new, ct_state=+est,
2427 ct_state=+rel, and ct_state=+trk-inv.
2428 Connection Tracking Original Direction IPv4 Source Address Field
2430 Name: ct_nw_src
2432 Width: 32 bits
2433 Format: IPv4
2434 Masking: arbitrary bitwise masks
2435 Prerequisites: CT
2436 Access: read-only
2437 OpenFlow 1.0: not supported
2438 OpenFlow 1.1: not supported
2439 OXM: none
2441 NXM: NXM_NX_CT_NW_SRC (120) since Open vSwitch 2.8
2442 Matches IPv4 conntrack original direction tuple source address. See the
2444 paragraphs above for general description to the conntrack original di‐
2445 rection tuple. Introduced in Open vSwitch 2.8.
2446 Connection Tracking Original Direction IPv4 Destination Address Field
2448 Name: ct_nw_dst
2450 Width: 32 bits
2451 Format: IPv4
2452 Masking: arbitrary bitwise masks
2454 Prerequisites: CT
2455 Access: read-only
2456 OpenFlow 1.0: not supported
2457 OpenFlow 1.1: not supported
2458 OXM: none
2459 NXM: NXM_NX_CT_NW_DST (121) since Open vSwitch 2.8
2460 Matches IPv4 conntrack original direction tuple destination address.
2462 See the paragraphs above for general description to the conntrack orig‐
2463 inal direction tuple. Introduced in Open vSwitch 2.8.
2464 Connection Tracking Original Direction IPv6 Source Address Field
2466 Name: ct_ipv6_src
2468 Width: 128 bits
2469 Format: IPv6
2470 Masking: arbitrary bitwise masks
2471 Prerequisites: CT
2472 Access: read-only
2473 OpenFlow 1.0: not supported
2474 OpenFlow 1.1: not supported
2475 OXM: none
2476 NXM: NXM_NX_CT_IPV6_SRC (122) since Open vSwitch 2.8
2477 Matches IPv6 conntrack original direction tuple source address. See the
2479 paragraphs above for general description to the conntrack original di‐
2480 rection tuple. Introduced in Open vSwitch 2.8.
2481 Connection Tracking Original Direction IPv6 Destination Address Field
2483 Name: ct_ipv6_dst
2485 Width: 128 bits
2486 Format: IPv6
2487 Masking: arbitrary bitwise masks
2488 Prerequisites: CT
2489 Access: read-only
2490 OpenFlow 1.0: not supported
2491 OpenFlow 1.1: not supported
2493 OXM: none
2494 NXM: NXM_NX_CT_IPV6_DST (123) since Open vSwitch 2.8
2495 Matches IPv6 conntrack original direction tuple destination address.
2497 See the paragraphs above for general description to the conntrack orig‐
2498 inal direction tuple. Introduced in Open vSwitch 2.8.
2499 Connection Tracking Original Direction IP Protocol Field
2501 Name: ct_nw_proto
2503 Width: 8 bits
2504 Format: decimal
2506 Masking: not maskable
2507 Prerequisites: CT
2508 Access: read-only
2509 OpenFlow 1.0: not supported
2510 OpenFlow 1.1: not supported
2511 OXM: none
2512 NXM: NXM_NX_CT_NW_PROTO (119) since Open vSwitch 2.8
2513 Matches conntrack original direction tuple IP protocol type, which is
2515 specified as a decimal number between 0 and 255, inclusive (e.g. 1 to
2516 match ICMP packets or 6 to match TCP packets). In case of, for example,
2517 an ICMP response to an UDP packet, this may be different from the IP
2518 protocol type of the packet itself. See the paragraphs above for gen‐
2519 eral description to the conntrack original direction tuple. Introduced
2520 in Open vSwitch 2.8.
2521 Connection Tracking Original Direction Transport Layer Source Port
2523 Field
2524 Name: ct_tp_src
2526 Width: 16 bits
2527 Format: decimal
2528 Masking: arbitrary bitwise masks
2529 Prerequisites: CT
2530 Access: read-only
2532 OpenFlow 1.0: not supported
2533 OpenFlow 1.1: not supported
2534 OXM: none
2535 NXM: NXM_NX_CT_TP_SRC (124) since Open vSwitch 2.8
2536 Bitwise match on the conntrack original direction tuple transport
2538 source, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or 132
2539 for SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58 for ICMPv6,
2540 the lower 8 bits of MFF_CT_TP_SRC matches the conntrack original direc‐
2541 tion ICMP type. See the paragraphs above for general description to the
2542 conntrack original direction tuple. Introduced in Open vSwitch 2.8.
2543 Connection Tracking Original Direction Transport Layer Source Port
2545 Field
2546 Name: ct_tp_dst
2548 Width: 16 bits
2549 Format: decimal
2550 Masking: arbitrary bitwise masks
2551 Prerequisites: CT
2552 Access: read-only
2553 OpenFlow 1.0: not supported
2554 OpenFlow 1.1: not supported
2555 OXM: none
2556 NXM: NXM_NX_CT_TP_DST (125) since Open vSwitch 2.8
2558 Bitwise match on the conntrack original direction tuple transport des‐
2560 tination port, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or
2561 132 for SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58 for
2562 ICMPv6, the lower 8 bits of MFF_CT_TP_DST matches the conntrack origi‐
2563 nal direction ICMP code. See the paragraphs above for general descrip‐
2564 tion to the conntrack original direction tuple. Introduced in Open
2565 vSwitch 2.8.
2566
2568 Summary:
2569 Name Bytes Mask RW? Prereqs NXM/OXM Support
2570 ───────── ────── ───── ──── ──────── ─────────────────────
2571 metadata 8 yes yes none OF 1.2+ and OVS 1.8+
2572 reg0 4 yes yes none OVS 1.1+
2573 reg1 4 yes yes none OVS 1.1+
2574 reg2 4 yes yes none OVS 1.1+
2576 reg3 4 yes yes none OVS 1.1+
2577 reg4 4 yes yes none OVS 1.3+
2578 reg5 4 yes yes none OVS 1.7+
2579 reg6 4 yes yes none OVS 1.7+
2580 reg7 4 yes yes none OVS 1.7+
2581 reg8 4 yes yes none OVS 2.6+
2582 reg9 4 yes yes none OVS 2.6+
2583 reg10 4 yes yes none OVS 2.6+
2585 reg11 4 yes yes none OVS 2.6+
2586 reg12 4 yes yes none OVS 2.6+
2587 reg13 4 yes yes none OVS 2.6+
2588 reg14 4 yes yes none OVS 2.6+
2589 reg15 4 yes yes none OVS 2.6+
2590 xreg0 8 yes yes none OF 1.3+ and OVS 2.4+
2591 xreg1 8 yes yes none OF 1.3+ and OVS 2.4+
2592 xreg2 8 yes yes none OF 1.3+ and OVS 2.4+
2594 xreg3 8 yes yes none OF 1.3+ and OVS 2.4+
2595 xreg4 8 yes yes none OF 1.3+ and OVS 2.4+
2596 xreg5 8 yes yes none OF 1.3+ and OVS 2.4+
2597 xreg6 8 yes yes none OF 1.3+ and OVS 2.4+
2598 xreg7 8 yes yes none OF 1.3+ and OVS 2.4+
2599 xxreg0 16 yes yes none OVS 2.6+
2600 xxreg1 16 yes yes none OVS 2.6+
2601 xxreg2 16 yes yes none OVS 2.6+
2603 xxreg3 16 yes yes none OVS 2.6+
2604 These fields give an OpenFlow switch space for temporary storage while
2606 the pipeline is running. Whereas metadata fields can have a meaningful
2607 initial value and can persist across some hops across OpenFlow
2608 switches, registers are always initially 0 and their values never per‐
2609 sist across inter-switch hops (not even across patch ports).
2610 OpenFlow Metadata Field
2612 Name: metadata
2614 Width: 64 bits
2615 Format: hexadecimal
2616 Masking: arbitrary bitwise masks
2617 Prerequisites: none
2618 Access: read/write
2619 OpenFlow 1.0: not supported
2621 OpenFlow 1.1: yes
2622 OXM: OXM_OF_METADATA [22m(2) since OpenFlow 1.2 and Open
2623 vSwitch 1.8
2624 NXM: none
2625 This field is the oldest standardized OpenFlow register field, intro‐
2627 duced in OpenFlow 1.1. It was introduced to model the limited number of
2628 user-defined bits that some ASIC-based switches can carry through their
2629 pipelines. Because of hardware limitations, OpenFlow allows switches to
2630 support writing and masking only an implementation-defined subset of
2631 bits, even no bits at all. The Open vSwitch software switch always sup‐
2632 ports all 64 bits, but of course an Open vSwitch port to an ASIC would
2633 have the same restriction as the ASIC itself.
2634 This field has an OXM code point, but OpenFlow 1.4 and earlier allow it
2636 to be modified only with a specialized instruction, not with a ``set-
2637 field’’ action. OpenFlow 1.5 removes this restriction. Open vSwitch
2638 does not enforce this restriction, regardless of OpenFlow version.
2639 Register 0 Field
2641 Name: reg0
2643 Width: 32 bits
2644 Format: hexadecimal
2645 Masking: arbitrary bitwise masks
2646 Prerequisites: none
2648 Access: read/write
2649 OpenFlow 1.0: not supported
2650 OpenFlow 1.1: not supported
2651 OXM: none
2652 NXM: NXM_NX_REG0 (0) since Open vSwitch 1.1
2653 This is the first of several Open vSwitch registers, all of which have
2655 the same properties. Open vSwitch 1.1 introduced registers 0, 1, 2, and
2656 3, version 1.3 added register 4, version 1.7 added registers 5, 6, and
2657 7, and version 2.6 added registers 8 through 15.
2658 Extended Register 0 Field
2660 Name: xreg0
2662 Width: 64 bits
2663 Format: hexadecimal
2664 Masking: arbitrary bitwise masks
2666 Prerequisites: none
2667 Access: read/write
2668 OpenFlow 1.0: not supported
2669 OpenFlow 1.1: not supported
2670 OXM: OXM_OF_PKT_REG0 [22m(0) since OpenFlow 1.3 and Open
2671 vSwitch 2.4
2672 NXM: none
2673 This is the first of the registers introduced in OpenFlow 1.5. OpenFlow
2675 1.5 calls these fields just the ``packet registers,’’ but Open vSwitch
2676 already had 32-bit registers by that name, so Open vSwitch uses the
2677 name ``extended registers’’ in an attempt to reduce confusion. The
2678 standard allows for up to 128 registers, each 64 bits wide, but Open
2679 vSwitch only implements 4 (in versions 2.4 and 2.5) or 8 (in version
2680 2.6 and later).
2681 Each of the 64-bit extended registers overlays two of the 32-bit regis‐
2683 ters: xreg0 overlays reg0 and reg1, with reg0 supplying the most-sig‐
2684 nificant bits of xreg0 and reg1 the least-significant. Similarly, xreg1
2685 overlays reg2 and reg3, and so on.
2686 The OpenFlow specification says, ``In most cases, the packet registers
2688 can not be matched in tables, i.e. they usually can not be used in the
2689 flow entry match structure’’ [OpenFlow 1.5, section 7.2.3.10], but
2690 there is no reason for a software switch to impose such a restriction,
2691 and Open vSwitch does not.
2692 Double-Extended Register 0 Field
2694 Name: xxreg0
2696 Width: 128 bits
2697 Format: hexadecimal
2698 Masking: arbitrary bitwise masks
2699 Prerequisites: none
2700 Access: read/write
2702 OpenFlow 1.0: not supported
2703 OpenFlow 1.1: not supported
2704 OXM: none
2705 NXM: NXM_NX_XXREG0 (111) since Open vSwitch 2.6
2706 This is the first of the double-extended registers introduce in Open
2708 vSwitch 2.6. Each of the 128-bit extended registers overlays four of
2709 the 32-bit registers: xxreg0 overlays reg0 through reg3, with reg0 sup‐
2710 plying the most-significant bits of xxreg0 and reg3 the least-signifi‐
2711 cant. xxreg1 similarly overlays reg4 through reg7, and so on.
2712
2714 Summary:
2715 Name Bytes Mask RW? Prereqs NXM/OXM Support
2716 ───────────────────── ────── ───── ──── ───────── ─────────────────────
2718 eth_src aka dl_src 6 yes yes Ethernet OF 1.2+ and OVS 1.1+
2719 eth_dst aka dl_dst 6 yes yes Ethernet OF 1.2+ and OVS 1.1+
2720 eth_type aka dl_type 2 no no Ethernet OF 1.2+ and OVS 1.1+
2721 Ethernet is the only layer-2 protocol that Open vSwitch supports. As
2723 with most software, Open vSwitch and OpenFlow regard an Ethernet frame
2724 to begin with the 14-byte header and end with the final byte of the
2725 payload; that is, the frame check sequence is not considered part of
2726 the frame.
2727 Ethernet Source Field
2729 Name: eth_src (aka dl_src)
2731 Width: 48 bits
2733 Format: Ethernet
2734 Masking: arbitrary bitwise masks
2735 Prerequisites: Ethernet
2736 Access: read/write
2738 OpenFlow 1.0: yes (exact match only)
2739 OpenFlow 1.1: yes
2740 OXM: OXM_OF_ETH_SRC (4) since OpenFlow 1.2 and Open vSwitch
2743 1.7
2744 NXM: NXM_OF_ETH_SRC (2) since Open vSwitch 1.1
2745 The Ethernet source address:
2747 Ethernet
2749 <---------->
2750 48 48 16
2751 +---+---+----+
2752 |dst|src|type| ...
2753 +---+---+----+
2754 Ethernet Destination Field
2757 Name: eth_dst (aka dl_dst)
2759 Width: 48 bits
2760 Format: Ethernet
2761 Masking: arbitrary bitwise masks
2763 Prerequisites: Ethernet
2764 Access: read/write
2765 OpenFlow 1.0: yes (exact match only)
2766 OpenFlow 1.1: yes
2768 OXM: OXM_OF_ETH_DST (3) since OpenFlow 1.2 and Open vSwitch
2769 1.7
2770 NXM: NXM_OF_ETH_DST (1) since Open vSwitch 1.1
2771 The Ethernet destination address:
2773 Ethernet
2775 <---------->
2776 48 48 16
2777 +---+---+----+
2778 |dst|src|type| ...
2779 +---+---+----+
2780 Open vSwitch 1.8 and later support arbitrary masks for source and/or
2783 destination. Earlier versions only support masking the destination with
2784 the following masks:
2785 01:00:00:00:00:00
2787 Match only the multicast bit. Thus,
2788 dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 matches all
2789 multicast (including broadcast) Ethernet packets, and
2790 dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 matches all
2791 unicast Ethernet packets.
2792 fe:ff:ff:ff:ff:ff
2794 Match all bits except the multicast bit. This is probably
2795 not useful.
2796 ff:ff:ff:ff:ff:ff
2798 Exact match (equivalent to omitting the mask).
2799 00:00:00:00:00:00
2801 Wildcard all bits (equivalent to dl_dst=*).
2802 Ethernet Type Field
2804 Name: eth_type (aka dl_type)
2806 Width: 16 bits
2807 Format: hexadecimal
2808 Masking: not maskable
2809 Prerequisites: Ethernet
2811 Access: read-only
2812 OpenFlow 1.0: yes (exact match only)
2813 OpenFlow 1.1: yes (exact match only)
2814 OXM: OXM_OF_ETH_TYPE [22m(5) since OpenFlow 1.2 and Open
2815 vSwitch 1.7
2816 NXM: NXM_OF_ETH_TYPE (3) since Open vSwitch 1.1
2818 The most commonly seen Ethernet frames today use a format called ``Eth‐
2820 ernet II,’’ in which the last two bytes of the Ethernet header specify
2821 the Ethertype. For such a frame, this field is copied from those bytes
2822 of the header, like so:
2823 Ethernet
2825 <---------------->
2826 48 48 16
2827 +---+---+----------+
2828 |dst|src| type | ...
2829 +---+---+----------+
2830 ≥0x600
2831 Every Ethernet type has a value 0x600 (1,536) or greater. When the last
2834 two bytes of the Ethernet header have a value too small to be an Ether‐
2835 net type, then the value found there is the total length of the frame
2836 in bytes, excluding the Ethernet header. An 802.2 LLC header typically
2837 follows the Ethernet header. OpenFlow and Open vSwitch only support LLC
2838 headers with DSAP and SSAP 0xaa and control byte 0x03, which indicate
2839 that a SNAP header follows the LLC header. In turn, OpenFlow and Open
2840 vSwitch only support a SNAP header with organization 0x000000. In such
2841 a case, this field is copied from the type field in the SNAP header,
2842 like this:
2843 Ethernet LLC SNAP
2845 <------------> <------------> <----------------->
2846 48 48 16 8 8 8 24 16
2847 +---+---+------+ +----+----+----+ +--------+----------+
2848 |dst|src| type | |DSAP|SSAP|cntl| | org | type | ...
2849 +---+---+------+ +----+----+----+ +--------+----------+
2850 <0x600 0xaa 0xaa 0x03 0x000000 ≥0x600
2851 When an 802.1Q header is inserted after the Ethernet source and desti‐
2854 nation, this field is populated with the encapsulated Ethertype, not
2855 the 802.1Q Ethertype. With an Ethernet II inner frame, the result looks
2856 like this:
2857 Ethernet 802.1Q Ethertype
2859 <------> <--------> <-------->
2860 48 48 16 16 16
2861 +----+---+ +------+---+ +----------+
2862 |dst |src| | TPID |TCI| | type | ...
2863 +----+---+ +------+---+ +----------+
2864 0x8100 ≥0x600
2865 LLC and SNAP encapsulation look like this with an 802.1Q header:
2868 Ethernet 802.1Q Ethertype LLC SNAP
2870 <------> <--------> <-------> <------------> <----------------->
2871 48 48 16 16 16 8 8 8 24 16
2872 +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2873 |dst |src| | TPID |TCI| | type | |DSAP|SSAP|cntl| | org | type | ...
2874 +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2875 0x8100 <0x600 0xaa 0xaa 0x03 0x000000 ≥0x600
2876 When a packet doesn’t match any of the header formats described above,
2879 Open vSwitch and OpenFlow set this field to 0x5ff
2880 (OFP_DL_TYPE_NOT_ETH_TYPE).
2881
2883 Summary:
2884 Name Bytes Mask RW? Prereqs NXM/OXM Support
2885 ──────────── ──────────────── ───── ──── ───────── ─────────────────────
2887 dl_vlan 2 (low 12 bits) no yes Ethernet
2888 dl_vlan_pcp 1 (low 3 bits) no yes Ethernet
2889 vlan_vid 2 (low 12 bits) yes yes Ethernet OF 1.2+ and OVS 1.7+
2891 vlan_pcp 1 (low 3 bits) no yes VLAN VID OF 1.2+ and OVS 1.7+
2892 vlan_tci 2 yes yes Ethernet OVS 1.1+
2893 The 802.1Q VLAN header causes more trouble than any other 4 bytes in
2895 networking. OpenFlow 1.0, 1.1, and 1.2+ all treat VLANs differently.
2896 Open vSwitch extensions add another variant to the mix. Open vSwitch
2897 reconciles all four treatments as best it can.
2898 VLAN Header Format
2900 An 802.1Q VLAN header consists of two 16-bit fields:
2901 TPID TCI
2903 <-------> <--------->
2904 16 3 1 12
2905 +---------+---+---+---+
2906 |Ethertype|PCP|CFI|VID|
2907 +---------+---+---+---+
2908 0x8100 0
2909 The first 16 bits of the VLAN header, the TPID (Tag Protocol IDenti‐
2912 fier), is an Ethertype. When the VLAN header is inserted just after the
2913 source and destination MAC addresses in a Ethertype frame, the TPID
2914 serves to identify the presence of the VLAN. The standard TPID, the
2915 only one that Open vSwitch supports, is 0x8100. OpenFlow 1.0 explicitly
2916 supports only TPID 0x8100. OpenFlow 1.1, but not earlier or later ver‐
2917 sions, also requires support for TPID 0x88a8 (Open vSwitch does not
2918 support this). OpenFlow 1.2 through 1.5 do not require support for spe‐
2919 cific TPIDs (the ``push vlan header’’ action does say that only 0x8100
2920 and 0x88a8 should be pushed). No version of OpenFlow provides a way to
2921 distinguish or match on the TPID.
2922 The remaining 16 bits of the VLAN header, the TCI (Tag Control Informa‐
2924 tion), is subdivided into three subfields:
2925 • PCP (Priority Control Point), is a 3-bit 802.1p priority.
2927 The lowest priority is value 1, the second-lowest is
2928 value 0, and priority increases from 2 up to highest pri‐
2929 ority 7.
2930 • CFI (Canonical Format Indicator), is a 1-bit field. On an
2932 Ethernet network, its value is always 0. This led to it
2933 later being repurposed under the name DEI (Drop Eligibil‐
2934 ity Indicator). By either name, OpenFlow and Open vSwitch
2935 don’t provide any way to match or set this bit.
2936 • VID (VLAN IDentifier), is a 12-bit VLAN. If the VID is 0,
2938 then the frame is not part of a VLAN. In that case, the
2939 VLAN header is called a priority tag because it is only
2940 meaningful for assigning the frame a priority. VID 0xfff
2941 (4,095) is reserved.
2942 See eth_type for illustrations of a complete Ethernet frame with 802.1Q
2944 tag included.
2945 Multiple VLANs
2947 Open vSwitch can match only a single VLAN header. If more than one VLAN
2948 header is present, then eth_type holds the TPID of the inner VLAN
2949 header. Open vSwitch stops parsing the packet after the inner TPID, so
2950 matching further into the packet (e.g. on the inner TCI or L3 fields)
2951 is not possible.
2952 OpenFlow only directly supports matching a single VLAN header. In Open‐
2954 Flow 1.1 or later, one OpenFlow table can match on the outermost VLAN
2955 header and pop it off, and a later OpenFlow table can match on the next
2956 outermost header. Open vSwitch does not support this.
2957 VLAN Field Details
2959 The four variants have three different levels of expressiveness: Open‐
2960 Flow 1.0 and 1.1 VLAN matching are less powerful than OpenFlow 1.2+
2961 VLAN matching, which is less powerful than Open vSwitch extension VLAN
2962 matching.
2963 OpenFlow 1.0 VLAN Fields
2965 OpenFlow 1.0 uses two fields, called dl_vlan and dl_vlan_pcp, each of
2966 which can be either exact-matched or wildcarded, to specify VLAN
2967 matches:
2968 • When both dl_vlan and dl_vlan_pcp are wildcarded, the
2970 flow matches packets without an 802.1Q header or with any
2971 802.1Q header.
2972 • The match dl_vlan=0xffff causes a flow to match only
2974 packets without an 802.1Q header. Such a flow should also
2975 wildcard dl_vlan_pcp, since a packet without an 802.1Q
2976 header does not have a PCP. OpenFlow does not specify
2977 what to do if a match on PCP is actually present, but
2978 Open vSwitch ignores it.
2979 • Otherwise, the flow matches only packets with an 802.1Q
2981 header. If dl_vlan is not wildcarded, then the flow only
2982 matches packets with the VLAN ID specified in dl_vlan’s
2983 low 12 bits. If dl_vlan_pcp is not wildcarded, then the
2984 flow only matches packets with the priority specified in
2985 dl_vlan_pcp’s low 3 bits.
2986 OpenFlow does not specify how to interpret the high 4
2988 bits of dl_vlan or the high 5 bits of dl_vlan_pcp. Open
2989 vSwitch ignores them.
2990 OpenFlow 1.1 VLAN Fields
2992 VLAN matching in OpenFlow 1.1 is similar to OpenFlow 1.0. The one re‐
2993 finement is that when dl_vlan matches on 0xfffe (OFVPID_ANY), the flow
2994 matches only packets with an 802.1Q header, with any VLAN ID. If
2995 dl_vlan_pcp is wildcarded, the flow matches any packet with an 802.1Q
2996 header, regardless of VLAN ID or priority. If dl_vlan_pcp is not wild‐
2997 carded, then the flow only matches packets with the priority specified
2998 in dl_vlan_pcp’s low 3 bits.
2999 OpenFlow 1.1 uses the name OFPVID_NONE, instead of OFP_VLAN_NONE, for a
3001 dl_vlan of 0xffff, but it has the same meaning.
3002 In OpenFlow 1.1, Open vSwitch reports error OFPBMC_BAD_VALUE for an at‐
3004 tempt to match on dl_vlan between 4,096 and 0xfffd, inclusive, or
3005 dl_vlan_pcp greater than 7.
3006 OpenFlow 1.2 VLAN Fields
3008 OpenFlow 1.2+ VLAN ID Field
3009 Name: vlan_vid
3011 Width: 16 bits (only the least-significant 12 bits may be nonzero)
3012 Format: decimal
3013 Masking: arbitrary bitwise masks
3014 Prerequisites: Ethernet
3015 Access: read/write
3016 OpenFlow 1.0: yes (exact match only)
3018 OpenFlow 1.1: yes (exact match only)
3019 OXM: OXM_OF_VLAN_VID (6) since OpenFlow 1.2 and Open vSwitch 1.7
3020 NXM: none
3021 The OpenFlow standard describes this field as consisting of ``12+1’’
3023 bits. On ingress, its value is 0 if no 802.1Q header is present, and
3024 otherwise it holds the VLAN VID in its least significant 12 bits, with
3025 bit 12 (0x1000 aka OFPVID_PRESENT) also set to 1. The three most sig‐
3026 nificant bits are always zero:
3027 OXM_OF_VLAN_VID
3029 <------------->
3030 3 1 12
3031 +---+--+--------+
3032 | |P |VLAN ID |
3033 +---+--+--------+
3034 0
3035 As a consequence of this field’s format, one may use it to match the
3038 VLAN ID in all of the ways available with the OpenFlow 1.0 and 1.1 for‐
3039 mats, and a few new ways:
3040 Fully wildcarded
3042 Matches any packet, that is, one without an 802.1Q header
3043 or with an 802.1Q header with any TCI value.
3044 Value 0x0000 (OFPVID_NONE), mask 0xffff (or no mask)
3046 Matches only packets without an 802.1Q header.
3047 Value 0x1000, mask 0x1000
3049 Matches any packet with an 802.1Q header, regardless of
3050 VLAN ID.
3051 Value 0x1009, mask 0xffff (or no mask)
3053 Match only packets with an 802.1Q header with VLAN ID 9.
3054 Value 0x1001, mask 0x1001
3056 Matches only packets that have an 802.1Q header with an
3057 odd-numbered VLAN ID. (This is just an example; one can
3058 match on any desired VLAN ID bit pattern.)
3059 OpenFlow 1.2+ VLAN Priority Field
3061 Name: vlan_pcp
3063 Width: 8 bits (only the least-significant 3 bits may be nonzero)
3064 Format: decimal
3065 Masking: not maskable
3067 Prerequisites: VLAN VID
3068 Access: read/write
3069 OpenFlow 1.0: yes (exact match only)
3070 OpenFlow 1.1: yes (exact match only)
3071 OXM: OXM_OF_VLAN_PCP [22m(7) since OpenFlow 1.2 and Open vSwitch
3074 1.7
3075 NXM: none
3076 The 3 least significant bits may be used to match the PCP bits in an
3078 802.1Q header. Other bits are always zero:
3079 OXM_OF_VLAN_VID
3081 <------------->
3082 5 3
3083 +--------+------+
3084 | zero | PCP |
3085 +--------+------+
3086 0
3087 This field may only be used when vlan_vid is not wildcarded and does
3090 not exact match on 0 (which only matches when there is no 802.1Q
3091 header).
3092 See VLAN Comparison Chart, below, for some examples.
3094 Open vSwitch Extension VLAN Field
3096 The vlan_tci extension can describe more kinds of VLAN matches than the
3097 other variants. It is also simpler than the other variants.
3098 VLAN TCI Field
3100 Name: vlan_tci
3102 Width: 16 bits
3103 Format: hexadecimal
3104 Masking: arbitrary bitwise masks
3105 Prerequisites: Ethernet
3106 Access: read/write
3107 OpenFlow 1.0: yes (exact match only)
3109 OpenFlow 1.1: yes (exact match only)
3110 OXM: none
3111 NXM: NXM_OF_VLAN_TCI (4) since Open vSwitch 1.1
3112 For a packet without an 802.1Q header, this field is zero. For a packet
3114 with an 802.1Q header, this field is the TCI with the bit in CFI’s po‐
3115 sition (marked P for ``present’’ below) forced to 1. Thus, for a packet
3116 in VLAN 9 with priority 7, it has the value 0xf009:
3117 NXM_VLAN_TCI
3119 <---------->
3120 3 1 12
3121 +----+--+----+
3122 |PCP |P |VID |
3123 +----+--+----+
3124 7 1 9
3125 Usage examples:
3128 vlan_tci=0
3130 Match packets without an 802.1Q header.
3131 vlan_tci=0x1000/0x1000
3133 Match packets with an 802.1Q header, regardless of VLAN
3134 and priority values.
3135 vlan_tci=0xf123
3137 Match packets tagged with priority 7 in VLAN 0x123.
3138 vlan_tci=0x1123/0x1fff
3140 Match packets tagged with VLAN 0x123 (and any priority).
3141 vlan_tci=0x5000/0xf000
3143 Match packets tagged with priority 2 (in any VLAN).
3144 vlan_tci=0/0xfff
3146 Match packets with no 802.1Q header or tagged with VLAN 0
3147 (and any priority).
3148 vlan_tci=0x5000/0xe000
3150 Match packets with no 802.1Q header or tagged with prior‐
3151 ity 2 (in any VLAN).
3152 vlan_tci=0/0xefff
3154 Match packets with no 802.1Q header or tagged with VLAN 0
3155 and priority 0.
3156 See VLAN Comparison Chart, below, for more examples.
3158 VLAN Comparison Chart
3160 The following table describes each of several possible matching crite‐
3161 ria on 802.1Q header may be expressed with each variation of the VLAN
3162 matching fields:
3163 Criteria OpenFlow 1.0 OpenFlow 1.1 OpenFlow 1.2+ NXM
3165 _ _ _ _ _
3166 [1] ????/1,??/? ????/1,??/? 0000/0000,-- 0000/0000
3168 [2] ffff/0,??/? ffff/0,??/? 0000/ffff,-- 0000/ffff
3169 [3] 0xxx/0,??/1 0xxx/0,??/1 1xxx/ffff,-- 1xxx/1fff
3170 [4] ????/1,0y/0 fffe/0,0y/0 1000/1000,0y z000/f000
3171 [5] 0xxx/0,0y/0 0xxx/0,0y/0 1xxx/ffff,0y zxxx/ffff
3172 [6] (none) (none) 1001/1001,-- 1001/1001
3173 [7] (none) (none) (none) 3000/3000
3174 [8] (none) (none) (none) 0000/0fff
3175 [9] (none) (none) (none) 0000/f000
3176 [10] (none) (none) (none) 0000/efff
3177 All numbers in the table are expressed in hexadecimal. The columns in
3179 the table are interpreted as follows:
3180 Criteria
3182 See the list below.
3183 OpenFlow 1.0
3185 OpenFlow 1.1
3186 wwww/x,yy/z means VLAN ID match value wwww with wildcard
3187 bit x and VLAN PCP match value yy with wildcard bit z. ?
3188 means that the given bits are ignored (and conventionally 0
3189 for wwww or yy, conventionally 1 for x or z). ``(none)’’
3190 means that OpenFlow 1.0 (or 1.1) cannot match with these
3191 criteria.
3192 OpenFlow 1.2+
3194 xxxx/yyyy,zz means vlan_vid with value xxxx and mask yyyy,
3195 and vlan_pcp (which is not maskable) with value zz. --
3196 means that vlan_pcp is omitted. ``(none)’’ means that Open‐
3197 Flow 1.2 cannot match with these criteria.
3198 NXM xxxx/yyyy means vlan_tci with value xxxx and mask yyyy.
3200 The matching criteria described by the table are:
3202 [1] Matches any packet, that is, one without an 802.1Q header
3204 or with an 802.1Q header with any TCI value.
3205 [2] Matches only packets without an 802.1Q header.
3207 OpenFlow 1.0 doesn’t define the behavior if dl_vlan is
3209 set to 0xffff and dl_vlan_pcp is not wildcarded. (Open
3210 vSwitch always ignores dl_vlan_pcp when dl_vlan is set to
3211 0xffff.)
3212 OpenFlow 1.1 says explicitly to ignore dl_vlan_pcp when
3214 dl_vlan is set to 0xffff.
3215 OpenFlow 1.2 doesn’t say how to interpret a match with
3217 vlan_vid value 0 and a mask with OFPVID_PRESENT (0x1000)
3218 set to 1 and some other bits in the mask set to 1 also.
3219 Open vSwitch interprets it the same way as a mask of
3220 0x1000.
3221 Any NXM match with vlan_tci value 0 and the CFI bit set
3223 to 1 in the mask is equivalent to the one listed in the
3224 table.
3225 [3] Matches only packets that have an 802.1Q header with VID
3227 xxx (and any PCP).
3228 [4] Matches only packets that have an 802.1Q header with PCP
3230 y (and any VID).
3231 OpenFlow 1.0 doesn’t clearly define the behavior for this
3233 case. Open vSwitch implements it this way.
3234 In the NXM value, z equals (y << 1) | 1.
3236 [5] Matches only packets that have an 802.1Q header with VID
3238 xxx and PCP y.
3239 In the NXM value, z equals (y << 1) | 1.
3241 [6] Matches only packets that have an 802.1Q header with an
3243 odd-numbered VID (and any PCP). Only possible with Open‐
3244 Flow 1.2 and NXM. (This is just an example; one can match
3245 on any desired VID bit pattern.)
3246 [7] Matches only packets that have an 802.1Q header with an
3248 odd-numbered PCP (and any VID). Only possible with NXM.
3249 (This is just an example; one can match on any desired
3250 VID bit pattern.)
3251 [8] Matches packets with no 802.1Q header or with an 802.1Q
3253 header with a VID of 0. Only possible with NXM.
3254 [9] Matches packets with no 802.1Q header or with an 802.1Q
3256 header with a PCP of 0. Only possible with NXM.
3257 [10] Matches packets with no 802.1Q header or with an 802.1Q
3259 header with both VID and PCP of 0. Only possible with
3260 NXM.
3262 Summary:
3263 Name Bytes Mask RW? Prereqs NXM/OXM Support
3264 ─────────── ──────────────── ───── ──── ──────── ──────────────────────
3266 mpls_label 4 (low 20 bits) no yes MPLS OF 1.2+ and OVS 1.11+
3267 mpls_tc 1 (low 3 bits) no yes MPLS OF 1.2+ and OVS 1.11+
3268 mpls_bos 1 (low 1 bits) no no MPLS OF 1.3+ and OVS 1.11+
3270 mpls_ttl 1 no yes MPLS OVS 2.6+
3271 One or more MPLS headers (more commonly called MPLS labels) follow an
3273 Ethernet type field that specifies an MPLS Ethernet type [RFC 3032].
3274 Ethertype 0x8847 is used for all unicast. Multicast MPLS is divided
3275 into two specific classes, one of which uses Ethertype 0x8847 and the
3276 other 0x8848 [RFC 5332].
3277 The most common overall packet format is Ethernet II, shown below (SNAP
3279 encapsulation may be used but is not ordinarily seen in Ethernet net‐
3280 works):
3281 Ethernet MPLS
3283 <------------> <------------>
3284 48 48 16 20 3 1 8
3285 +---+---+------+ +-----+--+-+---+
3286 |dst|src| type | |label|TC|S|TTL| ...
3287 +---+---+------+ +-----+--+-+---+
3288 0x8847
3289 MPLS can be encapsulated inside an 802.1Q header, in which case the
3292 combination looks like this:
3293 Ethernet 802.1Q Ethertype MPLS
3295 <------> <--------> <-------> <------------>
3296 48 48 16 16 16 20 3 1 8
3297 +----+---+ +------+---+ +---------+ +-----+--+-+---+
3298 |dst |src| | TPID |TCI| | type | |label|TC|S|TTL| ...
3299 +----+---+ +------+---+ +---------+ +-----+--+-+---+
3300 0x8100 0x8847
3301 The fields within an MPLS label are:
3304 Label, 20 bits.
3306 An identifier.
3307 Traffic control (TC), 3 bits.
3309 Used for quality of service.
3310 Bottom of stack (BOS), 1 bit (labeled just ``S’’ above).
3312 0 indicates that another MPLS label follows this one.
3313 1 indicates that this MPLS label is the last one in the
3315 stack, so that some other protocol follows this one.
3316 Time to live (TTL), 8 bits.
3318 Each hop across an MPLS network decrements the TTL by 1.
3319 If it reaches 0, the packet is discarded.
3320 OpenFlow does not make the MPLS TTL available as a match
3322 field, but actions are available to set and decrement the
3323 TTL. Open vSwitch 2.6 and later makes the MPLS TTL avail‐
3324 able as an extension.
3325 MPLS Label Stacks
3327 Unlike the other encapsulations supported by OpenFlow and Open vSwitch,
3328 MPLS labels are routinely used in ``stacks’’ two or three deep and
3329 sometimes even deeper. Open vSwitch currently supports up to three la‐
3330 bels.
3331 The OpenFlow specification only supports matching on the outermost MPLS
3333 label at any given time. To match on the second label, one must first
3334 ``pop’’ the outer label and advance to another OpenFlow table, where
3335 the inner label may be matched. To match on the third label, one must
3336 pop the two outer labels, and so on.
3337 MPLS Inner Protocol
3339 Unlike all other forms of encapsulation that Open vSwitch and OpenFlow
3340 support, an MPLS label does not indicate what inner protocol it encap‐
3341 sulates. Different deployments determine the inner protocol in differ‐
3342 ent ways [RFC 3032]:
3343 • A few reserved label values do indicate an inner proto‐
3345 col. Label 0, the ``IPv4 Explicit NULL Label,’’ indicates
3346 inner IPv4. Label 2, the ``IPv6 Explicit NULL Label,’’
3347 indicates inner IPv6.
3348 • Some deployments use a single inner protocol consis‐
3350 tently.
3351 • In some deployments, the inner protocol must be inferred
3353 from the innermost label.
3354 • In some deployments, the inner protocol must be inferred
3356 from the innermost label and the encapsulated data, e.g.
3357 to distinguish between inner IPv4 and IPv6 based on
3358 whether the first nibble of the inner protocol data are 4
3359 or 6. OpenFlow and Open vSwitch do not currently support
3360 these cases.
3361 Open vSwitch and OpenFlow do not infer the inner protocol, even if re‐
3363 served label values are in use. Instead, the flow table must specify
3364 the inner protocol at the time it pops the bottommost MPLS label, using
3365 the Ethertype argument to the pop_mpls action.
3366 Field Details
3368 MPLS Label Field
3369 Name: mpls_label
3371 Width: 32 bits (only the least-significant 20 bits may be nonzero)
3372 Format: decimal
3373 Masking: not maskable
3374 Prerequisites: MPLS
3375 Access: read/write
3376 OpenFlow 1.0: not supported
3377 OpenFlow 1.1: yes (exact match only)
3378 OXM: OXM_OF_MPLS_LABEL (34) since OpenFlow 1.2 and Open vSwitch
3380 1.11
3381 NXM: none
3382 The least significant 20 bits hold the ``label’’ field from the MPLS
3384 label. Other bits are zero:
3385 OXM_OF_MPLS_LABEL
3387 <--------------->
3388 12 20
3389 +--------+--------+
3390 | zero | label |
3391 +--------+--------+
3392 0
3393 Most label values are available for any use by deployments. Values un‐
3396 der 16 are reserved.
3397 MPLS Traffic Class Field
3399 Name: mpls_tc
3401 Width: 8 bits (only the least-significant 3 bits may be nonzero)
3402 Format: decimal
3403 Masking: not maskable
3404 Prerequisites: MPLS
3405 Access: read/write
3407 OpenFlow 1.0: not supported
3408 OpenFlow 1.1: yes (exact match only)
3409 OXM: OXM_OF_MPLS_TC [22m(35) since OpenFlow 1.2 and Open vSwitch
3410 1.11
3411 NXM: none
3412 The least significant 3 bits hold the TC field from the MPLS label.
3414 Other bits are zero:
3415 OXM_OF_MPLS_TC
3417 <------------>
3418 5 3
3419 +--------+-----+
3420 | zero | TC |
3421 +--------+-----+
3422 0
3423 This field is intended for use for Quality of Service (QoS) and Ex‐
3426 plicit Congestion Notification purposes, but its particular interpreta‐
3427 tion is deployment specific.
3428 Before 2009, this field was named EXP and reserved for experimental use
3430 [RFC 5462].
3431 MPLS Bottom of Stack Field
3433 Name: mpls_bos
3435 Width: 8 bits (only the least-significant 1 bits may be nonzero)
3436 Format: decimal
3437 Masking: not maskable
3438 Prerequisites: MPLS
3439 Access: read-only
3440 OpenFlow 1.0: not supported
3441 OpenFlow 1.1: not supported
3443 OXM: OXM_OF_MPLS_BOS (36) since OpenFlow 1.3 and Open vSwitch
3444 1.11
3445 NXM: none
3446 The least significant bit holds the BOS field from the MPLS label.
3448 Other bits are zero:
3449 OXM_OF_MPLS_BOS
3451 <------------->
3452 7 1
3453 +--------+------+
3454 | zero | BOS |
3455 +--------+------+
3456 0
3457 This field is useful as part of processing a series of incoming MPLS
3460 labels. A flow that includes a pop_mpls action should generally match
3461 on mpls_bos:
3462 • When mpls_bos is 0, there is another MPLS label following
3464 this one, so the Ethertype passed to pop_mpls should be
3465 an MPLS Ethertype. For example: table=0, dl_type=0x8847,
3466 mpls_bos=0, actions=pop_mpls:0x8847, goto_table:1
3467 • When mpls_bos is 1, this MPLS label is the last one, so
3469 the Ethertype passed to pop_mpls should be a non-MPLS
3470 Ethertype such as IPv4. For example: table=1,
3471 dl_type=0x8847, mpls_bos=1, actions=pop_mpls:0x0800,
3472 goto_table:2
3473 MPLS Time-to-Live Field
3475 Name: mpls_ttl
3477 Width: 8 bits
3478 Format: decimal
3479 Masking: not maskable
3481 Prerequisites: MPLS
3482 Access: read/write
3483 OpenFlow 1.0: not supported
3484 OpenFlow 1.1: not supported
3485 OXM: none
3486 NXM: NXM_NX_MPLS_TTL (30) since Open vSwitch 2.6
3487 Holds the 8-bit time-to-live field from the MPLS label:
3489 NXM_NX_MPLS_TTL
3491 <------------->
3492 8
3493 +---------------+
3494 | TTL |
3495 +---------------+
3496
3499 Summary:
3500 Name Bytes Mask RW? Prereqs NXM/OXM Support
3501 ────────────────────── ──────────────── ───── ──── ────────── ─────────────────────
3502 ip_src aka nw_src 4 yes yes IPv4 OF 1.2+ and OVS 1.1+
3503 ip_dst aka nw_dst 4 yes yes IPv4 OF 1.2+ and OVS 1.1+
3505 ipv6_src 16 yes yes IPv6 OF 1.2+ and OVS 1.1+
3506 ipv6_dst 16 yes yes IPv6 OF 1.2+ and OVS 1.1+
3507 ipv6_label 4 (low 20 bits) yes yes IPv6 OF 1.2+ and OVS 1.4+
3508 nw_proto aka ip_proto 1 no no IPv4/IPv6 OF 1.2+ and OVS 1.1+
3509 nw_ttl 1 no yes IPv4/IPv6 OVS 1.4+
3510 ip_frag aka nw_frag 1 (low 2 bits) yes no IPv4/IPv6 OVS 1.3+
3512 nw_tos 1 no yes IPv4/IPv6 OVS 1.1+
3513 ip_dscp 1 (low 6 bits) no yes IPv4/IPv6 OF 1.2+ and OVS 1.7+
3514 nw_ecn aka ip_ecn 1 (low 2 bits) no yes IPv4/IPv6 OF 1.2+ and OVS 1.4+
3515 IPv4 Specific Fields
3517 These fields are applicable only to IPv4 flows, that is, flows that
3518 match on the IPv4 Ethertype 0x0800.
3519 IPv4 Source Address Field
3521 Name: ip_src (aka nw_src)
3523 Width: 32 bits
3524 Format: IPv4
3525 Masking: arbitrary bitwise masks
3526 Prerequisites: IPv4
3528 Access: read/write
3529 OpenFlow 1.0: yes (CIDR match only)
3530 OpenFlow 1.1: yes
3531 OXM: OXM_OF_IPV4_SRC [22m(11) since OpenFlow 1.2 and Open
3532 vSwitch 1.7
3533 NXM: NXM_OF_IP_SRC (7) since Open vSwitch 1.1
3534 The source address from the IPv4 header:
3536 Ethernet IPv4
3538 <-----------> <--------------->
3539 48 48 16 8 32 32
3540 +---+---+-----+ +---+-----+---+---+
3541 |dst|src|type | |...|proto|src|dst| ...
3542 +---+---+-----+ +---+-----+---+---+
3543 0x800
3544 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3547 matches on nw_src as actually referring to the ARP SPA.
3548 IPv4 Destination Address Field
3550 Name: ip_dst (aka nw_dst)
3552 Width: 32 bits
3553 Format: IPv4
3554 Masking: arbitrary bitwise masks
3555 Prerequisites: IPv4
3556 Access: read/write
3557 OpenFlow 1.0: yes (CIDR match only)
3558 OpenFlow 1.1: yes
3560 OXM: OXM_OF_IPV4_DST [22m(12) since OpenFlow 1.2 and Open
3561 vSwitch 1.7
3562 NXM: NXM_OF_IP_DST (8) since Open vSwitch 1.1
3563 The destination address from the IPv4 header:
3565 Ethernet IPv4
3567 <-----------> <--------------->
3568 48 48 16 8 32 32
3569 +---+---+-----+ +---+-----+---+---+
3570 |dst|src|type | |...|proto|src|dst| ...
3571 +---+---+-----+ +---+-----+---+---+
3572 0x800
3573 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3576 matches on nw_dst as actually referring to the ARP TPA.
3577 IPv6 Specific Fields
3579 These fields apply only to IPv6 flows, that is, flows that match on the
3580 IPv6 Ethertype 0x86dd.
3581 IPv6 Source Address Field
3583 Name: ipv6_src
3585 Width: 128 bits
3586 Format: IPv6
3587 Masking: arbitrary bitwise masks
3588 Prerequisites: IPv6
3589 Access: read/write
3590 OpenFlow 1.0: not supported
3592 OpenFlow 1.1: not supported
3593 OXM: OXM_OF_IPV6_SRC [22m(26) since OpenFlow 1.2 and Open
3594 vSwitch 1.1
3595 NXM: NXM_NX_IPV6_SRC (19) since Open vSwitch 1.1
3596 The source address from the IPv6 header:
3598 Ethernet IPv6
3600 <------------> <-------------->
3601 48 48 16 8 128 128
3602 +---+---+------+ +---+----+---+---+
3603 |dst|src| type | |...|next|src|dst| ...
3604 +---+---+------+ +---+----+---+---+
3605 0x86dd
3606 Open vSwitch 1.8 added support for bitwise matching; earlier versions
3609 supported only CIDR masks.
3610 IPv6 Destination Address Field
3612 Name: ipv6_dst
3614 Width: 128 bits
3616 Format: IPv6
3617 Masking: arbitrary bitwise masks
3618 Prerequisites: IPv6
3619 Access: read/write
3620 OpenFlow 1.0: not supported
3621 OpenFlow 1.1: not supported
3622 OXM: OXM_OF_IPV6_DST [22m(27) since OpenFlow 1.2 and Open
3624 vSwitch 1.1
3625 NXM: NXM_NX_IPV6_DST (20) since Open vSwitch 1.1
3626 The destination address from the IPv6 header:
3628 Ethernet IPv6
3630 <------------> <-------------->
3631 48 48 16 8 128 128
3632 +---+---+------+ +---+----+---+---+
3633 |dst|src| type | |...|next|src|dst| ...
3634 +---+---+------+ +---+----+---+---+
3635 0x86dd
3636 Open vSwitch 1.8 added support for bitwise matching; earlier versions
3639 supported only CIDR masks.
3640 IPv6 Flow Label Field
3642 Name: ipv6_label
3644 Width: 32 bits (only the least-significant 20 bits may be nonzero)
3645 Format: hexadecimal
3646 Masking: arbitrary bitwise masks
3648 Prerequisites: IPv6
3649 Access: read/write
3650 OpenFlow 1.0: not supported
3651 OpenFlow 1.1: not supported
3652 OXM: OXM_OF_IPV6_FLABEL (28) since OpenFlow 1.2 and Open vSwitch
3653 1.7
3654 NXM: NXM_NX_IPV6_LABEL (27) since Open vSwitch 1.4
3656 The least significant 20 bits hold the flow label field from the IPv6
3658 header. Other bits are zero:
3659 OXM_OF_IPV6_FLABEL
3661 <---------------->
3662 12 20
3663 +--------+---------+
3664 | zero | label |
3665 +--------+---------+
3666 0
3667 IPv4/IPv6 Fields
3670 These fields exist with at least approximately the same meaning in both
3671 IPv4 and IPv6, so they are treated as a single field for matching pur‐
3672 poses. Any flow that matches on the IPv4 Ethertype 0x0800 or the IPv6
3673 Ethertype 0x86dd may match on these fields.
3674 IPv4/v6 Protocol Field
3676 Name: nw_proto (aka ip_proto)
3678 Width: 8 bits
3679 Format: decimal
3680 Masking: not maskable
3682 Prerequisites: IPv4/IPv6
3683 Access: read-only
3684 OpenFlow 1.0: yes (exact match only)
3685 OpenFlow 1.1: yes (exact match only)
3686 OXM: OXM_OF_IP_PROTO [22m(10) since OpenFlow 1.2 and Open
3687 vSwitch 1.7
3688 NXM: NXM_OF_IP_PROTO (6) since Open vSwitch 1.1
3689 Matches the IPv4 or IPv6 protocol type.
3691 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3693 matches on nw_proto as actually referring to the ARP opcode. The ARP
3694 opcode is a 16-bit field, so for matching purposes ARP opcodes greater
3695 than 255 are treated as 0; this works adequately because in practice
3696 ARP and RARP only use opcodes 1 through 4.
3697 In the case of fragmented traffic, a difference exists in the way the
3699 field acts for IPv4 and IPv6 later fragments. For IPv6 fragments with
3700 nonzero offset, nw_proto is set to the IPv6 protocol type for fragments
3701 (44). Conversely, for IPv4 later fragments, the field is set based on
3702 the protocol type present in the header.
3703 IPv4/v6 TTL/Hop Limit Field
3705 Name: nw_ttl
3707 Width: 8 bits
3709 Format: decimal
3710 Masking: not maskable
3711 Prerequisites: IPv4/IPv6
3712 Access: read/write
3713 OpenFlow 1.0: not supported
3714 OpenFlow 1.1: not supported
3715 OXM: none
3716 NXM: NXM_NX_IP_TTL (29) since Open vSwitch 1.4
3718 The main reason to match on the TTL or hop limit field is to detect
3720 whether a dec_ttl action will fail due to a TTL exceeded error. Another
3721 way that a controller can detect TTL exceeded is to listen for OFPR_IN‐
3722 VALID_TTL ``packet-in’’ messages via OpenFlow.
3723 IPv4/v6 Fragment Bitmask Field
3725 Name: ip_frag (aka nw_frag)
3727 Width: 8 bits (only the least-significant 2 bits may be nonzero)
3728 Format: frag
3729 Masking: arbitrary bitwise masks
3730 Prerequisites: IPv4/IPv6
3731 Access: read-only
3732 OpenFlow 1.0: not supported
3733 OpenFlow 1.1: not supported
3734 OXM: none
3736 NXM: NXM_NX_IP_FRAG (26) since Open vSwitch 1.3
3737 Specifies what kinds of IP fragments or non-fragments to match. The
3739 value for this field is most conveniently specified as one of the fol‐
3740 lowing:
3741 no Match only non-fragmented packets.
3743 yes Matches all fragments.
3745 first Matches only fragments with offset 0.
3747 later Matches only fragments with nonzero offset.
3749 not_later
3751 Matches non-fragmented packets and fragments with zero
3752 offset.
3753 The field is internally formatted as 2 bits: bit 0 is 1 for an IP frag‐
3755 ment with any offset (and otherwise 0), and bit 1 is 1 for an IP frag‐
3756 ment with nonzero offset (and otherwise 0), like so:
3757 NXM_NX_IP_FRAG
3759 <------------>
3760 6 1 1
3761 +----+-----+---+
3762 |zero|later|any|
3763 +----+-----+---+
3764 0
3765 Even though 2 bits have 4 possible values, this field only uses 3 of
3768 them:
3769 • A packet that is not an IP fragment has value 0.
3771 • A packet that is an IP fragment with offset 0 (the first
3773 fragment) has bit 0 set and thus value 1.
3774 • A packet that is an IP fragment with nonzero offset has
3776 bits 0 and 1 set and thus value 3.
3777 The switch may reject matches against values that can never appear.
3779 It is important to understand how this field interacts with the Open‐
3781 Flow fragment handling mode:
3782 • In OFPC_FRAG_DROP mode, the OpenFlow switch drops all IP
3784 fragments before they reach the flow table, so every
3785 packet that is available for matching will have value 0
3786 in this field.
3787 • Open vSwitch does not implement OFPC_FRAG_REASM mode, but
3789 if it did then IP fragments would be reassembled before
3790 they reached the flow table and again every packet avail‐
3791 able for matching would always have value 0.
3792 • In OFPC_FRAG_NORMAL mode, all three values are possible,
3794 but OpenFlow 1.0 says that fragments’ transport ports are
3795 always 0, even for the first fragment, so this does not
3796 provide much extra information.
3797 • In OFPC_FRAG_NX_MATCH mode, all three values are possi‐
3799 ble. For fragments with offset 0, Open vSwitch makes L4
3800 header information available.
3801 Thus, this field is likely to be most useful for an Open vSwitch switch
3803 configured in OFPC_FRAG_NX_MATCH mode. See the description of the
3804 set-frags command in ovs-ofctl(8), for more details.
3805 IPv4/IPv6 TOS Fields
3807 IPv4 and IPv6 contain a one-byte ``type of service’’ or TOS field that
3809 has the following format:
3810 type of service
3812 <------------->
3813 6 2
3814 +--------+------+
3815 | DSCP | ECN |
3816 +--------+------+
3817 IPv4/v6 DSCP (Bits 2-7) Field
3820 Name: nw_tos
3823 Width: 8 bits
3824 Format: decimal
3825 Masking: not maskable
3826 Prerequisites: IPv4/IPv6
3827 Access: read/write
3828 OpenFlow 1.0: yes (exact match only)
3829 OpenFlow 1.1: yes (exact match only)
3830 OXM: none
3831 NXM: NXM_OF_IP_TOS (5) since Open vSwitch 1.1
3833 This field is the TOS byte with the two ECN bits cleared to 0:
3835 NXM_OF_IP_TOS
3837 <----------->
3838 6 2
3839 +------+------+
3840 | DSCP | zero |
3841 +------+------+
3842 0
3843 IPv4/v6 DSCP (Bits 0-5) Field
3846 Name: ip_dscp
3848 Width: 8 bits (only the least-significant 6 bits may be nonzero)
3849 Format: decimal
3850 Masking: not maskable
3851 Prerequisites: IPv4/IPv6
3853 Access: read/write
3854 OpenFlow 1.0: yes (exact match only)
3855 OpenFlow 1.1: yes (exact match only)
3856 OXM: OXM_OF_IP_DSCP [22m(8) since OpenFlow 1.2 and Open vSwitch
3857 1.7
3858 NXM: none
3859 This field is the TOS byte shifted right to put the DSCP bits in the 6
3861 least-significant bits:
3862 OXM_OF_IP_DSCP
3864 <------------>
3865 2 6
3866 +-------+------+
3867 | zero | DSCP |
3868 +-------+------+
3869 0
3870 IPv4/v6 ECN Field
3873 Name: nw_ecn (aka ip_ecn)
3875 Width: 8 bits (only the least-significant 2 bits may be nonzero)
3876 Format: decimal
3877 Masking: not maskable
3878 Prerequisites: IPv4/IPv6
3879 Access: read/write
3880 OpenFlow 1.0: not supported
3881 OpenFlow 1.1: yes (exact match only)
3883 OXM: OXM_OF_IP_ECN (9) since OpenFlow 1.2 and Open vSwitch 1.7
3884 NXM: NXM_NX_IP_ECN (28) since Open vSwitch 1.4
3885 This field is the TOS byte with the DSCP bits cleared to 0:
3887 OXM_OF_IP_ECN
3889 <----------->
3890 6 2
3891 +-------+-----+
3892 | zero | ECN |
3893 +-------+-----+
3894 0
3895
3898 Summary:
3899 Name Bytes Mask RW? Prereqs NXM/OXM Support
3900 ──────── ────── ───── ──── ──────── ─────────────────────
3902 arp_op 2 no yes ARP OF 1.2+ and OVS 1.1+
3903 arp_spa 4 yes yes ARP OF 1.2+ and OVS 1.1+
3904 arp_tpa 4 yes yes ARP OF 1.2+ and OVS 1.1+
3905 arp_sha 6 yes yes ARP OF 1.2+ and OVS 1.1+
3907 arp_tha 6 yes yes ARP OF 1.2+ and OVS 1.1+
3908 In theory, Address Resolution Protocol, or ARP, is a generic protocol
3910 generic protocol that can be used to obtain the hardware address that
3911 corresponds to any higher-level protocol address. In contemporary us‐
3912 age, ARP is used only in Ethernet networks to obtain the Ethernet ad‐
3913 dress for a given IPv4 address. OpenFlow and Open vSwitch only support
3914 this usage of ARP. For this use case, an ARP packet has the following
3915 format, with the ARP fields exposed as Open vSwitch fields highlighted:
3916 Ethernet ARP
3918 <-----------> <---------------------------------->
3919 48 48 16 16 16 8 8 16 48 16 48 16
3920 +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3921 |dst|src|type | |hrd| pro |hln|pln|op|sha|spa|tha|tpa|
3922 +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3923 0x806 1 0x800 6 4
3924 The ARP fields are also used for RARP, the Reverse Address Resolution
3927 Protocol, which shares ARP’s wire format.
3928 ARP Opcode Field
3930 Name: arp_op
3932 Width: 16 bits
3933 Format: decimal
3934 Masking: not maskable
3935 Prerequisites: ARP
3937 Access: read/write
3938 OpenFlow 1.0: yes (exact match only)
3939 OpenFlow 1.1: yes (exact match only)
3940 OXM: OXM_OF_ARP_OP (21) since OpenFlow 1.2 and Open vSwitch
3942 1.7
3943 NXM: NXM_OF_ARP_OP (15) since Open vSwitch 1.1
3944 Even though this is a 16-bit field, Open vSwitch does not support ARP
3946 opcodes greater than 255; it treats them to zero. This works adequately
3947 because in practice ARP and RARP only use opcodes 1 through 4.
3948 ARP Source IPv4 Address Field
3950 Name: arp_spa
3952 Width: 32 bits
3953 Format: IPv4
3954 Masking: arbitrary bitwise masks
3955 Prerequisites: ARP
3957 Access: read/write
3958 OpenFlow 1.0: yes (CIDR match only)
3959 OpenFlow 1.1: yes
3960 OXM: OXM_OF_ARP_SPA [22m(22) since OpenFlow 1.2 and Open
3962 vSwitch 1.7
3963 NXM: NXM_OF_ARP_SPA (16) since Open vSwitch 1.1
3964 ARP Target IPv4 Address Field
3966 Name: arp_tpa
3968 Width: 32 bits
3969 Format: IPv4
3970 Masking: arbitrary bitwise masks
3972 Prerequisites: ARP
3973 Access: read/write
3974 OpenFlow 1.0: yes (CIDR match only)
3975 OpenFlow 1.1: yes
3977 OXM: OXM_OF_ARP_TPA [22m(23) since OpenFlow 1.2 and Open
3978 vSwitch 1.7
3979 NXM: NXM_OF_ARP_TPA (17) since Open vSwitch 1.1
3980 ARP Source Ethernet Address Field
3982 Name: arp_sha
3984 Width: 48 bits
3985 Format: Ethernet
3987 Masking: arbitrary bitwise masks
3988 Prerequisites: ARP
3989 Access: read/write
3990 OpenFlow 1.0: not supported
3992 OpenFlow 1.1: not supported
3993 OXM: OXM_OF_ARP_SHA [22m(24) since OpenFlow 1.2 and Open
3994 vSwitch 1.7
3995 NXM: NXM_NX_ARP_SHA (17) since Open vSwitch 1.1
3997 ARP Target Ethernet Address Field
3999 Name: arp_tha
4002 Width: 48 bits
4003 Format: Ethernet
4004 Masking: arbitrary bitwise masks
4005 Prerequisites: ARP
4007 Access: read/write
4008 OpenFlow 1.0: not supported
4009 OpenFlow 1.1: not supported
4010 OXM: OXM_OF_ARP_THA [22m(25) since OpenFlow 1.2 and Open
4012 vSwitch 1.7
4013 NXM: NXM_NX_ARP_THA (18) since Open vSwitch 1.1
4014
4016 Summary:
4017 Name Bytes Mask RW? Prereqs NXM/OXM Support
4018 ───────────────── ──────────────── ───── ──── ──────── ────────────────
4020 nsh_flags 1 yes yes NSH OVS 2.8+
4021 nsh_ttl 1 no yes NSH OVS 2.9+
4022 nsh_mdtype 1 no no NSH OVS 2.8+
4023 nsh_np 1 no no NSH OVS 2.8+
4025 nsh_spi aka nsp 4 (low 24 bits) no yes NSH OVS 2.8+
4026 nsh_si aka nsi 1 no yes NSH OVS 2.8+
4027 nsh_c1 aka nshc1 4 yes yes NSH OVS 2.8+
4028 nsh_c2 aka nshc2 4 yes yes NSH OVS 2.8+
4030 nsh_c3 aka nshc3 4 yes yes NSH OVS 2.8+
4031 nsh_c4 aka nshc4 4 yes yes NSH OVS 2.8+
4032 Service functions are widely deployed and essential in many networks.
4034 These service functions provide a range of features such as security,
4035 WAN acceleration, and server load balancing. Service functions may be
4036 instantiated at different points in the network infrastructure such as
4037 the wide area network, data center, and so forth.
4038 Prior to development of the SFC architecture [RFC 7665] and the proto‐
4040 col specified in this document, current service function deployment
4041 models have been relatively static and bound to topology for insertion
4042 and policy selection. Furthermore, they do not adapt well to elastic
4043 service environments enabled by virtualization.
4044 New data center network and cloud architectures require more flexible
4046 service function deployment models. Additionally, the transition to
4047 virtual platforms demands an agile service insertion model that sup‐
4048 ports dynamic and elastic service delivery. Specifically, the following
4049 functions are necessary:
4050 1. The movement of service functions and application workloads
4052 in the network.
4053 2. The ability to easily bind service policy to granular infor‐
4055 mation, such as per-subscriber state.
4056 3. The capability to steer traffic to the requisite service
4058 function(s).
4059 The Network Service Header (NSH) specification defines a new data plane
4061 protocol, which is an encapsulation for service function chains. The
4062 NSH is designed to encapsulate an original packet or frame, and in turn
4063 be encapsulated by an outer transport encapsulation (which is used to
4064 deliver the NSH to NSH-aware network elements), as shown below:
4065 +-----------------------+----------------------------+---------------------+
4067 |Transport Encapsulation|Network Service Header (NSH)|Original Packet/Frame|
4068 +-----------------------+----------------------------+---------------------+
4069 The NSH is composed of the following elements:
4072 1. Service Function Path identification.
4074 2. Indication of location within a Service Function Path.
4076 3. Optional, per packet metadata (fixed length or variable).
4078 [RFC 7665] provides an overview of a service chaining architecture that
4080 clearly defines the roles of the various elements and the scope of a
4081 service function chaining encapsulation. Figure 3 of [RFC 7665] depicts
4082 the SFC architectural components after classification. The NSH is the
4083 SFC encapsulation referenced in [RFC 7665].
4084 flags field (2 bits) Field
4086 Name: nsh_flags
4088 Width: 8 bits
4089 Format: decimal
4090 Masking: arbitrary bitwise masks
4091 Prerequisites: NSH
4092 Access: read/write
4094 OpenFlow 1.0: not supported
4095 OpenFlow 1.1: not supported
4096 OXM: none
4097 NXM: NXOXM_NSH_FLAGS (1) since Open vSwitch 2.8
4098 TTL field (6 bits) Field
4100 Name: nsh_ttl
4102 Width: 8 bits
4103 Format: decimal
4104 Masking: not maskable
4106 Prerequisites: NSH
4107 Access: read/write
4108 OpenFlow 1.0: not supported
4109 OpenFlow 1.1: not supported
4110 OXM: none
4112 NXM: NXOXM_NSH_TTL (10) since Open vSwitch 2.9
4113 mdtype field (8 bits) Field
4115 Name: nsh_mdtype
4118 Width: 8 bits
4119 Format: decimal
4120 Masking: not maskable
4121 Prerequisites: NSH
4122 Access: read-only
4124 OpenFlow 1.0: not supported
4125 OpenFlow 1.1: not supported
4126 OXM: none
4127 NXM: NXOXM_NSH_MDTYPE (2) since Open vSwitch 2.8
4128 np (next protocol) field (8 bits) Field
4130 Name: nsh_np
4132 Width: 8 bits
4133 Format: decimal
4134 Masking: not maskable
4136 Prerequisites: NSH
4137 Access: read-only
4138 OpenFlow 1.0: not supported
4139 OpenFlow 1.1: not supported
4140 OXM: none
4142 NXM: NXOXM_NSH_NP (3) since Open vSwitch 2.8
4143 spi (service path identifier) field (24 bits) Field
4145 Name: nsh_spi (aka nsp)
4148 Width: 32 bits (only the least-significant 24 bits may be nonzero)
4149 Format: hexadecimal
4150 Masking: not maskable
4151 Prerequisites: NSH
4152 Access: read/write
4154 OpenFlow 1.0: not supported
4155 OpenFlow 1.1: not supported
4156 OXM: none
4157 NXM: NXOXM_NSH_SPI (4) since Open vSwitch 2.8
4158 si (service index) field (8 bits) Field
4160 Name: nsh_si (aka nsi)
4162 Width: 8 bits
4163 Format: decimal
4164 Masking: not maskable
4166 Prerequisites: NSH
4167 Access: read/write
4168 OpenFlow 1.0: not supported
4169 OpenFlow 1.1: not supported
4170 OXM: none
4172 NXM: NXOXM_NSH_SI (5) since Open vSwitch 2.8
4173 c1 (Network Platform Context) field (32 bits) Field
4175 Name: nsh_c1 (aka nshc1)
4178 Width: 32 bits
4179 Format: hexadecimal
4180 Masking: arbitrary bitwise masks
4181 Prerequisites: NSH
4182 Access: read/write
4184 OpenFlow 1.0: not supported
4185 OpenFlow 1.1: not supported
4186 OXM: none
4187 NXM: NXOXM_NSH_C1 (6) since Open vSwitch 2.8
4188 c2 (Network Shared Context) field (32 bits) Field
4190 Name: nsh_c2 (aka nshc2)
4192 Width: 32 bits
4193 Format: hexadecimal
4194 Masking: arbitrary bitwise masks
4196 Prerequisites: NSH
4197 Access: read/write
4198 OpenFlow 1.0: not supported
4199 OpenFlow 1.1: not supported
4200 OXM: none
4202 NXM: NXOXM_NSH_C2 (7) since Open vSwitch 2.8
4203 c3 (Service Platform Context) field (32 bits) Field
4205 Name: nsh_c3 (aka nshc3)
4208 Width: 32 bits
4209 Format: hexadecimal
4210 Masking: arbitrary bitwise masks
4211 Prerequisites: NSH
4212 Access: read/write
4214 OpenFlow 1.0: not supported
4215 OpenFlow 1.1: not supported
4216 OXM: none
4217 NXM: NXOXM_NSH_C3 (8) since Open vSwitch 2.8
4218 c4 (Service Shared Context) field (32 bits) Field
4220 Name: nsh_c4 (aka nshc4)
4222 Width: 32 bits
4223 Format: hexadecimal
4224 Masking: arbitrary bitwise masks
4226 Prerequisites: NSH
4227 Access: read/write
4228 OpenFlow 1.0: not supported
4229 OpenFlow 1.1: not supported
4230 OXM: none
4232 NXM: NXOXM_NSH_C4 (9) since Open vSwitch 2.8
4233
4235 Summary:
4236 Name Bytes Mask RW? Prereqs NXM/OXM Support
4237 ─────────────────── ──────────────── ───── ──── ──────── ─────────────────────
4239 tcp_src aka tp_src 2 yes yes TCP OF 1.2+ and OVS 1.1+
4240 tcp_dst aka tp_dst 2 yes yes TCP OF 1.2+ and OVS 1.1+
4241 tcp_flags 2 (low 12 bits) yes no TCP OF 1.3+ and OVS 2.1+
4242 udp_src 2 yes yes UDP OF 1.2+ and OVS 1.1+
4244 udp_dst 2 yes yes UDP OF 1.2+ and OVS 1.1+
4245 sctp_src 2 yes yes SCTP OF 1.2+ and OVS 2.0+
4246 sctp_dst 2 yes yes SCTP OF 1.2+ and OVS 2.0+
4247 For matching purposes, no distinction is made whether these protocols
4249 are encapsulated within IPv4 or IPv6.
4250 TCP
4252 The following diagram shows TCP within IPv4. Open vSwitch also supports
4253 TCP in IPv6. Only TCP fields implemented as Open vSwitch fields are
4254 shown:
4255 Ethernet IPv4 TCP
4257 <-----------> <---------------> <------------------->
4258 48 48 16 8 32 32 16 16 12
4259 +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4260 |dst|src|type | |...|proto|src|dst| |src|dst|...|flags|...| ...
4261 +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4262 0x800 6
4263 TCP Source Port Field
4266 Name: tcp_src (aka tp_src)
4268 Width: 16 bits
4269 Format: decimal
4270 Masking: arbitrary bitwise masks
4271 Prerequisites: TCP
4273 Access: read/write
4274 OpenFlow 1.0: yes (exact match only)
4275 OpenFlow 1.1: yes (exact match only)
4276 OXM: OXM_OF_TCP_SRC [22m(13) since OpenFlow 1.2 and Open
4279 vSwitch 1.7
4280 NXM: NXM_OF_TCP_SRC (9) since Open vSwitch 1.1
4281 Open vSwitch 1.6 added support for bitwise matching.
4283 TCP Destination Port Field
4285 Name: tcp_dst (aka tp_dst)
4287 Width: 16 bits
4288 Format: decimal
4289 Masking: arbitrary bitwise masks
4291 Prerequisites: TCP
4292 Access: read/write
4293 OpenFlow 1.0: yes (exact match only)
4294 OpenFlow 1.1: yes (exact match only)
4295 OXM: OXM_OF_TCP_DST [22m(14) since OpenFlow 1.2 and Open
4297 vSwitch 1.7
4298 NXM: NXM_OF_TCP_DST (10) since Open vSwitch 1.1
4299 Open vSwitch 1.6 added support for bitwise matching.
4301 TCP Flags Field
4303 Name: tcp_flags
4305 Width: 16 bits (only the least-significant 12 bits may be nonzero)
4306 Format: TCP flags
4307 Masking: arbitrary bitwise masks
4309 Prerequisites: TCP
4310 Access: read-only
4311 OpenFlow 1.0: not supported
4312 OpenFlow 1.1: not supported
4313 OXM: ONFOXM_ET_TCP_FLAGS [22m(42) since OpenFlow 1.3 and Open
4315 vSwitch 2.4; OXM_OF_TCP_FLAGS (42) since OpenFlow 1.5 and
4316 Open vSwitch 2.3
4317 NXM: NXM_NX_TCP_FLAGS (34) since Open vSwitch 2.1
4318 This field holds the TCP flags. TCP currently defines 9 flag bits. An
4320 additional 3 bits are reserved. For more information, see [RFC 793],
4321 [RFC 3168], and [RFC 3540].
4322 Matches on this field are most conveniently written in terms of sym‐
4324 bolic names (given in the diagram below), each preceded by either + for
4325 a flag that must be set, or - for a flag that must be unset, without
4326 any other delimiters between the flags. Flags not mentioned are wild‐
4327 carded. For example, tcp,tcp_flags=+syn-ack matches TCP SYNs that are
4328 not ACKs, and tcp,tcp_flags=+[200] matches TCP packets with the re‐
4329 served [200] flag set. Matches can also be written as flags/mask, where
4330 flags and mask are 16-bit numbers in decimal or in hexadecimal prefixed
4331 by 0x.
4332 The flag bits are:
4334 reserved later RFCs RFC 793
4336 <---------------> <--------> <--------------------->
4337 4 1 1 1 1 1 1 1 1 1 1 1 1
4338 +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4339 |zero|[800]|[400]|[200]|NS|CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|
4340 +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4341 0
4342 UDP
4345 The following diagram shows UDP within IPv4. Open vSwitch also supports
4346 UDP in IPv6. Only UDP fields that Open vSwitch exposes as fields are
4347 shown:
4348 Ethernet IPv4 UDP
4350 <-----------> <---------------> <--------->
4351 48 48 16 8 32 32 16 16
4352 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4353 |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4354 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4355 0x800 17
4356 UDP Source Port Field
4359 Name: udp_src
4361 Width: 16 bits
4363 Format: decimal
4364 Masking: arbitrary bitwise masks
4365 Prerequisites: UDP
4366 Access: read/write
4367 OpenFlow 1.0: yes (exact match only)
4369 OpenFlow 1.1: yes (exact match only)
4370 OXM: OXM_OF_UDP_SRC [22m(15) since OpenFlow 1.2 and Open
4371 vSwitch 1.7
4372 NXM: NXM_OF_UDP_SRC (11) since Open vSwitch 1.1
4373 UDP Destination Port Field
4375 Name: udp_dst
4377 Width: 16 bits
4378 Format: decimal
4379 Masking: arbitrary bitwise masks
4381 Prerequisites: UDP
4382 Access: read/write
4383 OpenFlow 1.0: yes (exact match only)
4384 OpenFlow 1.1: yes (exact match only)
4385 OXM: OXM_OF_UDP_DST [22m(16) since OpenFlow 1.2 and Open
4387 vSwitch 1.7
4388 NXM: NXM_OF_UDP_DST (12) since Open vSwitch 1.1
4389 SCTP
4391 The following diagram shows SCTP within IPv4. Open vSwitch also sup‐
4392 ports SCTP in IPv6. Only SCTP fields that Open vSwitch exposes as
4393 fields are shown:
4394 Ethernet IPv4 SCTP
4396 <-----------> <---------------> <--------->
4397 48 48 16 8 32 32 16 16
4398 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4399 |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4400 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4401 0x800 132
4402 SCTP Source Port Field
4405 Name: sctp_src
4408 Width: 16 bits
4409 Format: decimal
4410 Masking: arbitrary bitwise masks
4411 Prerequisites: SCTP
4412 Access: read/write
4413 OpenFlow 1.0: not supported
4415 OpenFlow 1.1: yes (exact match only)
4416 OXM: OXM_OF_SCTP_SRC [22m(17) since OpenFlow 1.2 and Open
4417 vSwitch 2.0
4418 NXM: none
4419 SCTP Destination Port Field
4421 Name: sctp_dst
4423 Width: 16 bits
4424 Format: decimal
4425 Masking: arbitrary bitwise masks
4426 Prerequisites: SCTP
4427 Access: read/write
4429 OpenFlow 1.0: not supported
4430 OpenFlow 1.1: yes (exact match only)
4431 OXM: OXM_OF_SCTP_DST [22m(18) since OpenFlow 1.2 and Open
4432 vSwitch 2.0
4433 NXM: none
4434
4436 Summary:
4437 Name Bytes Mask RW? Prereqs NXM/OXM Support
4438 ──────────────── ────── ───── ──── ─────────── ─────────────────────
4439 icmp_type 1 no yes ICMPv4 OF 1.2+ and OVS 1.1+
4441 icmp_code 1 no yes ICMPv4 OF 1.2+ and OVS 1.1+
4442 icmpv6_type 1 no yes ICMPv6 OF 1.2+ and OVS 1.1+
4443 icmpv6_code 1 no yes ICMPv6 OF 1.2+ and OVS 1.1+
4444 nd_target 16 yes yes ND OF 1.2+ and OVS 1.1+
4445 nd_sll 6 yes yes ND solicit OF 1.2+ and OVS 1.1+
4447 nd_tll 6 yes yes ND advert OF 1.2+ and OVS 1.1+
4448 nd_reserved 4 no yes ND OVS 2.11+
4449 nd_options_type 1 no yes ND OVS 2.11+
4450 ICMPv4
4452 Ethernet IPv4 ICMPv4
4453 <-----------> <---------------> <----------->
4454 48 48 16 8 32 32 8 8
4455 +---+---+-----+ +---+-----+---+---+ +----+----+---+
4456 |dst|src|type | |...|proto|src|dst| |type|code|...| ...
4457 +---+---+-----+ +---+-----+---+---+ +----+----+---+
4458 0x800 1
4459 ICMPv4 Type Field
4462 Name: icmp_type
4464 Width: 8 bits
4465 Format: decimal
4466 Masking: not maskable
4467 Prerequisites: ICMPv4
4468 Access: read/write
4469 OpenFlow 1.0: yes (exact match only)
4471 OpenFlow 1.1: yes (exact match only)
4472 OXM: OXM_OF_ICMPV4_TYPE [22m(19) since OpenFlow 1.2 and Open
4473 vSwitch 1.7
4474 NXM: NXM_OF_ICMP_TYPE (13) since Open vSwitch 1.1
4475 For historical reasons, in an ICMPv4 flow, Open vSwitch interprets
4477 matches on tp_src as actually referring to the ICMP type.
4478 ICMPv4 Code Field
4480 Name: icmp_code
4482 Width: 8 bits
4483 Format: decimal
4484 Masking: not maskable
4485 Prerequisites: ICMPv4
4487 Access: read/write
4488 OpenFlow 1.0: yes (exact match only)
4489 OpenFlow 1.1: yes (exact match only)
4490 OXM: OXM_OF_ICMPV4_CODE [22m(20) since OpenFlow 1.2 and Open
4491 vSwitch 1.7
4492 NXM: NXM_OF_ICMP_CODE (14) since Open vSwitch 1.1
4493 For historical reasons, in an ICMPv4 flow, Open vSwitch interprets
4495 matches on tp_dst as actually referring to the ICMP code.
4496 ICMPv6
4498 Ethernet IPv6 ICMPv6
4499 <------------> <--------------> <----------->
4500 48 48 16 8 128 128 8 8
4501 +---+---+------+ +---+----+---+---+ +----+----+---+
4502 |dst|src| type | |...|next|src|dst| |type|code|...| ...
4503 +---+---+------+ +---+----+---+---+ +----+----+---+
4504 0x86dd 58
4505 ICMPv6 Type Field
4508 Name: icmpv6_type
4511 Width: 8 bits
4512 Format: decimal
4513 Masking: not maskable
4514 Prerequisites: ICMPv6
4515 Access: read/write
4516 OpenFlow 1.0: not supported
4517 OpenFlow 1.1: not supported
4519 OXM: OXM_OF_ICMPV6_TYPE [22m(29) since OpenFlow 1.2 and Open
4520 vSwitch 1.7
4521 NXM: NXM_NX_ICMPV6_TYPE (21) since Open vSwitch 1.1
4522 ICMPv6 Code Field
4524 Name: icmpv6_code
4527 Width: 8 bits
4528 Format: decimal
4529 Masking: not maskable
4530 Prerequisites: ICMPv6
4531 Access: read/write
4532 OpenFlow 1.0: not supported
4533 OpenFlow 1.1: not supported
4535 OXM: OXM_OF_ICMPV6_CODE (30) since OpenFlow 1.2 and Open
4536 vSwitch 1.7
4537 NXM: NXM_NX_ICMPV6_CODE (22) since Open vSwitch 1.1
4538 ICMPv6 Neighbor Discovery
4540 Ethernet IPv6 ICMPv6 ICMPv6 ND
4541 <------------> <--------------> <--------------> <--------------->
4542 48 48 16 8 128 128 8 8 128
4543 +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4544 |dst|src| type | |...|next|src|dst| | type |code|...| |target|option ...|
4545 +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4546 0x86dd 58 135/136 0
4547 ICMPv6 Neighbor Discovery Target IPv6 Field
4550 Name: nd_target
4552 Width: 128 bits
4553 Format: IPv6
4554 Masking: arbitrary bitwise masks
4555 Prerequisites: ND
4556 Access: read/write
4557 OpenFlow 1.0: not supported
4559 OpenFlow 1.1: not supported
4560 OXM: OXM_OF_IPV6_ND_TARGET (31) since OpenFlow 1.2 and Open
4561 vSwitch 1.7
4562 NXM: NXM_NX_ND_TARGET (23) since Open vSwitch 1.1
4563 ICMPv6 Neighbor Discovery Source Ethernet Address Field
4565 Name: nd_sll
4567 Width: 48 bits
4568 Format: Ethernet
4569 Masking: arbitrary bitwise masks
4570 Prerequisites: ND solicit
4571 Access: read/write
4572 OpenFlow 1.0: not supported
4573 OpenFlow 1.1: not supported
4575 OXM: OXM_OF_IPV6_ND_SLL (32) since OpenFlow 1.2 and Open
4576 vSwitch 1.7
4577 NXM: NXM_NX_ND_SLL (24) since Open vSwitch 1.1
4578 ICMPv6 Neighbor Discovery Target Ethernet Address Field
4580 Name: nd_tll
4583 Width: 48 bits
4584 Format: Ethernet
4585 Masking: arbitrary bitwise masks
4586 Prerequisites: ND advert
4587 Access: read/write
4588 OpenFlow 1.0: not supported
4589 OpenFlow 1.1: not supported
4591 OXM: OXM_OF_IPV6_ND_TLL [22m(33) since OpenFlow 1.2 and Open
4592 vSwitch 1.7
4593 NXM: NXM_NX_ND_TLL (25) since Open vSwitch 1.1
4594 ICMPv6 Neighbor Discovery Reserved Field Field
4596 Name: nd_reserved
4599 Width: 32 bits
4600 Format: decimal
4601 Masking: not maskable
4602 Prerequisites: ND
4603 Access: read/write
4604 OpenFlow 1.0: not supported
4605 OpenFlow 1.1: not supported
4607 OXM: none
4608 NXM: ERICOXM_OF_ICMPV6_ND_RESERVED (1) since Open vSwitch
4609 2.11
4610 This is used to set the R,S,O bits in Neighbor Advertisement Messages
4612 ICMPv6 Neighbor Discovery Options Type Field Field
4614 Name: nd_options_type
4616 Width: 8 bits
4617 Format: decimal
4618 Masking: not maskable
4619 Prerequisites: ND
4620 Access: read/write
4621 OpenFlow 1.0: not supported
4623 OpenFlow 1.1: not supported
4624 OXM: none
4625 NXM: ERICOXM_OF_ICMPV6_ND_OPTIONS_TYPE [22m(2) since Open
4626 vSwitch 2.11
4627 A value of 1 indicates that the option is Source Link Layer. A value of
4629 2 indicates that the options is Target Link Layer. See RFC 4861 for
4630 further details.
4631
4633 Casado M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown,
4634 and S. Shenker, ``Ethane: Taking Control of the Enter‐
4635 prise,’’ Computer Communications Review, October 2007.
4636 ERSPAN M. Foschiano, K. Ghosh, M. Mehta, ``Cisco Systems’ Encap‐
4638 sulated Remote Switch Port Analyzer (ERSPAN),’’ ⟨https://
4639 tools.ietf.org/html/draft-foschiano-erspan-03⟩ .
4640 EXT-56 J. Tonsing, ``Permit one of a set of prerequisites to ap‐
4642 ply, e.g. don’t preclude non-Ethernet media,’’ ⟨https://
4643 rs.opennetworking.org/bugs/browse/EXT-56⟩ (ONF members
4644 only).
4645 EXT-112
4647 J. Tourrilhes, ``Support non-Ethernet packets throughout
4648 the pipeline,’’ ⟨https://rs.opennetworking.org/bugs/
4649 browse/EXT-112⟩ (ONF members only).
4650 EXT-134
4652 J. Tourrilhes, ``Match first nibble of the MPLS pay‐
4653 load,’’ ⟨https://rs.opennetworking.org/bugs/browse/
4654 EXT-134⟩ (ONF members only).
4655 Geneve J. Gross, I. Ganga, and T. Sridhar, editors, ``Geneve:
4657 Generic Network Virtualization Encapsulation,’’ ⟨https://
4658 datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/⟩ .
4659 IEEE OUI
4661 IEEE Standards Association, ``MAC Address Block Large
4662 (MA-L),’’ ⟨https://standards.ieee.org/develop/regauth/
4663 oui/index.html⟩ .
4664 NSH P. Quinn and U. Elzur, editors, ``Network Service
4666 Header,’’ ⟨https://datatracker.ietf.org/doc/
4667 draft-ietf-sfc-nsh/⟩ .
4668 OpenFlow 1.0.1
4670 Open Networking Foundation, ``OpenFlow Switch Errata,
4671 Version 1.0.1,’’ June 2012.
4672 OpenFlow 1.1
4674 OpenFlow Consortium, ``OpenFlow Switch Specification Ver‐
4675 sion 1.1.0 Implemented (Wire Protocol 0x02),’’ February
4676 2011.
4677 OpenFlow 1.5
4679 Open Networking Foundation, ``OpenFlow Switch Specifica‐
4680 tion Version 1.5.0 (Protocol version 0x06),’’ December
4681 2014.
4682 OpenFlow Extensions 1.3.x Package 2
4684 Open Networking Foundation, ``OpenFlow Extensions 1.3.x
4685 Package 2,’’ December 2013.
4686 TCP Flags Match Field Extension
4688 Open Networking Foundation, ``TCP flags match field Ex‐
4689 tension,’’ December 2014. In [OpenFlow Extensions 1.3.x
4690 Package 2].
4691 Pepelnjak
4693 I. Pepelnjak, ``OpenFlow and Fermi Estimates,’’ ⟨http://
4694 blog.ipspace.net/2013/09/openflow-and-fermi-esti‐
4695 mates.html⟩ .
4696 RFC 793
4698 ``Transmission Control Protocol,’’ ⟨http://www.ietf.org/
4699 rfc/rfc793.txt⟩ .
4700 RFC 3032
4702 E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Fari‐
4703 nacci, T. Li, and A. Conta, ``MPLS Label Stack Encod‐
4704 ing,’’ ⟨http://www.ietf.org/rfc/rfc3032.txt⟩ .
4705 RFC 3168
4707 K. Ramakrishnan, S. Floyd, and D. Black, ``The Addition
4708 of Explicit Congestion Notification (ECN) to IP,’’
4709 ⟨https://tools.ietf.org/html/rfc3168⟩ .
4710 RFC 3540
4712 N. Spring, D. Wetherall, and D. Ely, ``Robust Explicit
4713 Congestion Notification (ECN) Signaling with Nonces,’’
4714 ⟨https://tools.ietf.org/html/rfc3540⟩ .
4715 RFC 4632
4717 V. Fuller and T. Li, ``Classless Inter-domain Routing
4718 (CIDR): The Internet Address Assignment and Aggregation
4719 Plan,’’ ⟨https://tools.ietf.org/html/rfc4632⟩ .
4720 RFC 5462
4722 L. Andersson and R. Asati, ``Multiprotocol Label Switch‐
4723 ing (MPLS) Label Stack Entry: ``EXP’’ Field Renamed to
4724 ``Traffic Class’’ Field,’’ ⟨http://www.ietf.org/rfc/
4725 rfc5462.txt⟩ .
4726 RFC 6830
4728 D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, ``The
4729 Locator/ID Separation Protocol (LISP),’’ ⟨http://
4730 www.ietf.org/rfc/rfc6830.txt⟩ .
4731 RFC 7348
4733 M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger,
4734 T. Sridhar, M. Bursell, and C. Wright, ``Virtual eXtensi‐
4735 ble Local Area Network (VXLAN): A Framework for Overlay‐
4736 ing Virtualized Layer 2 Networks over Layer 3 Networks,
4737 ’’ ⟨https://tools.ietf.org/html/rfc7348⟩ .
4738 RFC 7665
4740 J. Halpern, Ed. and C. Pignataro, Ed., ``Service Function
4741 Chaining (SFC) Architecture,’’ ⟨https://tools.ietf.org/
4742 html/rfc7665⟩ .
4743 Srinivasan
4745 V. Srinivasan, S. Suriy, and G. Varghese, ``Packet Clas‐
4746 sification using Tuple Space Search,’’ SIGCOMM 1999.
4747 Pagiamtzis
4749 K. Pagiamtzis and A. Sheikholeslami, ``Content-address‐
4750 able memory (CAM) circuits and architectures: A tutorial
4751 and survey,’’ IEEE Journal of Solid-State Circuits, vol.
4752 41, no. 3, pp. 712-727, March 2006.
4753 VXLAN Group Policy Option
4755 M. Smith and L. Kreeger, `` VXLAN Group Policy Option.’’
4756 Internet-Draft. ⟨https://tools.ietf.org/html/
4757 draft-smith-vxlan-group-policy⟩ .
4758
4760 Ben Pfaff, with advice from Justin Pettit and Jean Tourrilhes.
4761Open vSwitch 3.1.1 ovs-fields(7)