1ovs-fields(7) Open vSwitch Manual ovs-fields(7)
2
6 ovs-fields - protocol header fields in OpenFlow and Open vSwitch
7
9 This document aims to comprehensively document all of the fields, both
10 standard and non-standard, supported by OpenFlow or Open vSwitch,
11 regardless of origin.
12 Fields
14 A field is a property of a packet. Most familiarly, data fields are
15 fields that can be extracted from a packet. Most data fields are copied
16 directly from protocol headers, e.g. at layer 2, the Ethernet source
17 and destination addresses, or the VLAN ID; at layer 3, the IPv4 or IPv6
18 source and destination; and at layer 4, the TCP or UDP ports. Other
19 data fields are computed, e.g. ip_frag describes whether a packet is a
20 fragment but it is not copied directly from the IP header.
21 Data fields that are always present as a consequence of the basic net‐
23 working technology in use are called called root fields. Open vSwitch
24 2.7 and earlier considered Ethernet fields to be root fields, and this
25 remains the default mode of operation for Open vSwitch bridges. When a
26 packet is received from a non-Ethernet interfaces, such as a layer-3
27 LISP tunnel, Open vSwitch 2.7 and earlier force-fit the packet to this
28 Ethernet-centric point of view by pretending that an Ethernet header is
29 present whose Ethernet type that indicates the packet’s actual type
30 (and whose source and destination addresses are all-zero).
31 Open vSwitch 2.8 and later implement the ``packet type-aware pipeline’’
33 concept introduced in OpenFlow 1.5. Such a pipeline does not have any
34 root fields. Instead, a new metadata field, packet_type, indicates the
35 basic type of the packet, which can be Ethernet, IPv4, IPv6, or another
36 type. For backward compatibility, by default Open vSwitch 2.8 imitates
37 the behavior of Open vSwitch 2.7 and earlier. Later versions of Open
38 vSwitch may change the default, and in the meantime controllers can
39 turn off this legacy behavior, on a port-by-port basis, by setting
40 options:packet_type to ptap in the Interface table. This is significant
41 only for ports that can handle non-Ethernet packets, which is currently
42 just LISP, VXLAN-GPE, and GRE tunnel ports. See ovs-vwitchd.conf.db(5)
43 for more information.
44 Non-root data fields are not always present. A packet contains ARP
46 fields, for example, only when its packet type is ARP or when it is an
47 Ethernet packet whose Ethernet header indicates the Ethertype for ARP,
48 0x0806. In this documentation, we say that a field is applicable when
49 it is present in a packet, and inapplicable when it is not. (These are
50 not standard terms.) We refer to the conditions that determine whether
51 a field is applicable as prerequisites. Some VLAN-related fields are a
52 special case: these fields are always applicable for Ethernet packets,
53 but have a designated value or bit that indicates whether a VLAN header
54 is present, with the remaining values or bits indicating the VLAN
55 header’s content (if it is present).
56 An inapplicable field does not have a value, not even a nominal
58 ``value’’ such as all-zero-bits. In many circumstances, OpenFlow and
59 Open vSwitch allow references only to applicable fields. For example,
60 one may match (see Matching, below) a given field only if the match
61 includes the field’s prerequisite, e.g. matching an ARP field is only
62 allowed if one also matches on Ethertype 0x0806 or the packet_type for
63 ARP in a packet type-aware bridge.
64 Sometimes a packet may contain multiple instances of a header. For
66 example, a packet may contain multiple VLAN or MPLS headers, and tun‐
67 nels can cause any data field to recur. OpenFlow and Open vSwitch do
68 not address these cases uniformly. For VLAN and MPLS headers, only the
69 outermost header is accessible, so that inner headers may be accessed
70 only by ``popping’’ (removing) the outer header. (Open vSwitch supports
71 only a single VLAN header in any case.) For tunnels, e.g. GRE or VXLAN,
72 the outer header and inner headers are treated as different data
73 fields.
74 Many network protocols are built in layers as a stack of concatenated
76 headers. Each header typically contains a ``next type’’ field that
77 indicates the type of the protocol header that follows, e.g. Ethernet
78 contains an Ethertype and IPv4 contains a IP protocol type. The excep‐
79 tional cases, where protocols are layered but an outer layer does not
80 indicate the protocol type for the inner layer, or gives only an
81 ambiguous indication, are troublesome. An MPLS header, for example,
82 only indicates whether another MPLS header or some other protocol fol‐
83 lows, and in the latter case the inner protocol must be known from the
84 context. In these exceptional cases, OpenFlow and Open vSwitch cannot
85 provide insight into the inner protocol data fields without additional
86 context, and thus they treat all later data fields as inapplicable
87 until an OpenFlow action explicitly specifies what protocol follows. In
88 the case of MPLS, the OpenFlow ``pop MPLS’’ action that removes the
89 last MPLS header from a packet provides this context, as the Ethertype
90 of the payload. See Layer 2.5: MPLS for more information.
91 OpenFlow and Open vSwitch support some fields other than data fields.
93 Metadata fields relate to the origin or treatment of a packet, but they
94 are not extracted from the packet data itself. One example is the phys‐
95 ical port on which a packet arrived at the switch. Register fields act
96 like variables: they give an OpenFlow switch space for temporary stor‐
97 age while processing a packet. Existing metadata and register fields
98 have no prerequisites.
99 A field’s value consists of an integral number of bytes. For data
101 fields, sometimes those bytes are taken directly from the packet. Other
102 data fields are copied from a packet with padding (usually with zeros
103 and in the most significant positions). The remaining data fields are
104 transformed in other ways as they are copied from the packets, to make
105 them more useful for matching.
106 Matching
108 The most important use of fields in OpenFlow is matching, to determine
109 whether particular field values agree with a set of constraints called
110 a match. A match consists of zero or more constraints on individual
111 fields, all of which must be met to satisfy the match. (A match that
112 contains no constraints is always satisfied.) OpenFlow and Open vSwitch
113 support a number of forms of matching on individual fields:
114 Exact match, e.g. nw_src=10.1.2.3
116 Only a particular value of the field is matched; for
117 example, only one particular source IP address. Exact
118 matches are written as field=value. The forms accepted
119 for value depend on the field.
120 All fields support exact matches.
122 Bitwise match, e.g. nw_src=10.1.0.0/255.255.0.0
124 Specific bits in the field must have specified values;
125 for example, only source IP addresses in a particular
126 subnet. Bitwise matches are written as field=value/mask,
127 where value and mask take one of the forms accepted for
128 an exact match on field. Some fields accept other forms
129 for bitwise matches; for example,
130 nw_src=10.1.0.0/255.255.0.0 may also be written
131 nw_src=10.1.0.0/16.
132 Most OpenFlow switches do not allow every bitwise match‐
134 ing on every field (and before OpenFlow 1.2, the protocol
135 did not even provide for the possibility for most
136 fields). Even switches that do allow bitwise matching on
137 a given field may restrict the masks that are allowed,
138 e.g. by allowing matches only on contiguous sets of bits
139 starting from the most significant bit, that is, ``CIDR’’
140 masks [RFC 4632]. Open vSwitch does not allows bitwise
141 matching on every field, but it allows arbitrary bitwise
142 masks on any field that does support bitwise matching.
143 (Older versions had some restrictions, as documented in
144 the descriptions of individual fields.)
145 Wildcard, e.g. ``any nw_src’’
147 The value of the field is not constrained. Wildcarded
148 fields may be written as field=*, although it is unusual
149 to mention them at all. (When specifying a wildcard
150 explicitly in a command invocation, be sure to using
151 quoting to protect against shell expansion.)
152 There is a tiny difference between wildcarding a field
154 and not specifying any match on a field: wildcarding a
155 field requires satisfying the field’s prerequisites.
156 Some types of matches on individual fields cannot be expressed directly
158 with OpenFlow and Open vSwitch. These can be expressed indirectly:
159 Set match, e.g. ``tcp_dst ∈ {80, 443, 8080}’’
161 The value of a field is one of a specified set of values;
162 for example, the TCP destination port is 80, 443, or
163 8080.
164 For matches used in flows (see Flows, below), multiple
166 flows can simulate set matches.
167 Range match, e.g. ``1000 ≤ tcp_dst ≤ 1999’’
169 The value of the field must lie within a numerical range,
170 for example, TCP destination ports between 1000 and 1999.
171 Range matches can be expressed as a collection of bitwise
173 matches. For example, suppose that the goal is to match
174 TCP source ports 1000 to 1999, inclusive. The binary rep‐
175 resentations of 1000 and 1999 are:
176 01111101000
178 11111001111
179 The following series of bitwise matches will match 1000
182 and 1999 and all the values in between:
183 01111101xxx
185 0111111xxxx
186 10xxxxxxxxx
187 110xxxxxxxx
188 1110xxxxxxx
189 11110xxxxxx
190 1111100xxxx
191 which can be written as the following matches:
194 tcp,tp_src=0x03e8/0xfff8
196 tcp,tp_src=0x03f0/0xfff0
197 tcp,tp_src=0x0400/0xfe00
198 tcp,tp_src=0x0600/0xff00
199 tcp,tp_src=0x0700/0xff80
200 tcp,tp_src=0x0780/0xffc0
201 tcp,tp_src=0x07c0/0xfff0
202 Inequality match, e.g. ``tcp_dst ≠ 80’’
205 The value of the field differs from a specified value,
206 for example, all TCP destination ports except 80.
207 An inequality match on an n-bit field can be expressed as
209 a disjunction of n 1-bit matches. For example, the
210 inequality match ``vlan_pcp ≠ 5’’ can be expressed as
211 ``vlan_pcp = 0/4 or vlan_pcp = 2/2 or vlan_pcp = 0/1.’’
212 For matches used in flows (see Flows, below), sometimes
213 one can more compactly express inequality as a higher-
214 priority flow that matches the exceptional case paired
215 with a lower-priority flow that matches the general case.
216 Alternatively, an inequality match may be converted to a
218 pair of range matches, e.g. tcp_src ≠ 80 may be expressed
219 as ``0 ≤ tcp_src < 80 or 80 < tcp_src ≤ 65535’’, and then
220 each range match may in turn be converted to a bitwise
221 match.
222 Conjunctive match, e.g. ``tcp_src ∈ {80, 443, 8080} and tcp_dst
224 ∈ {80, 443, 8080}’’
225 As an OpenFlow extension, Open vSwitch supports matching
226 on conditions on conjunctions of the previously mentioned
227 forms of matching. See the documentation for conj_id for
228 more information.
229 All of these supported forms of matching are special cases of bitwise
231 matching. In some cases this influences the design of field values.
232 ip_frag is the most prominent example: it is designed to make all of
233 the practically useful checks for IP fragmentation possible as a single
234 bitwise match.
235 Shorthands
237 Some matches are very commonly used, so Open vSwitch accepts shorthand
239 notations. In some cases, Open vSwitch also uses shorthand notations
240 when it displays matches. The following shorthands are defined, with
241 their long forms shown on the right side:
242 eth packet_type=(0,0) (Open vSwitch 2.8 and later)
244 ip eth_type=0x0800
246 ipv6 eth_type=0x86dd
248 icmp eth_type=0x0800,ip_proto=1
250 icmp6 eth_type=0x86dd,ip_proto=58
252 tcp eth_type=0x0800,ip_proto=6
254 tcp6 eth_type=0x86dd,ip_proto=6
256 udp eth_type=0x0800,ip_proto=17
258 udp6 eth_type=0x86dd,ip_proto=17
260 sctp eth_type=0x0800,ip_proto=132
262 sctp6 eth_type=0x86dd,ip_proto=132
264 arp eth_type=0x0806
266 rarp eth_type=0x8035
268 mpls eth_type=0x8847
270 mplsm eth_type=0x8848
272 Evolution of OpenFlow Fields
274 The discussion so far applies to all OpenFlow and Open vSwitch ver‐
275 sions. This section starts to draw in specific information by explain‐
276 ing, in broad terms, the treatment of fields and matches in each Open‐
277 Flow version.
278 OpenFlow 1.0
280 OpenFlow 1.0 defined the OpenFlow protocol format of a match as a
282 fixed-length data structure that could match on the following fields:
283 · Ingress port.
285 · Ethernet source and destination MAC.
287 · Ethertype (with a special value to match frames that lack
289 an Ethertype).
290 · VLAN ID and priority.
292 · IPv4 source, destination, protocol, and DSCP.
294 · TCP source and destination port.
296 · UDP source and destination port.
298 · ICMPv4 type and code.
300 · ARP IPv4 addresses (SPA and TPA) and opcode.
302 Each supported field corresponded to some member of the data structure.
304 Some members represented multiple fields, in the case of the TCP, UDP,
305 ICMPv4, and ARP fields whose presence is mutually exclusive. This also
306 meant that some members were poor fits for their fields: only the low 8
307 bits of the 16-bit ARP opcode could be represented, and the ICMPv4 type
308 and code were padded with 8 bits of zeros to fit in the 16-bit members
309 primarily meant for TCP and UDP ports. An additional bitmap member
310 indicated, for each member, whether its field should be an ``exact’’ or
311 ``wildcarded’’ match (see Matching), with additional support for CIDR
312 prefix matching on the IPv4 source and destination fields.
313 Simplicity was recognized early on as the main virtue of this approach.
315 Obviously, any fixed-length data structure cannot support matching new
316 protocols that do not fit. There was no room, for example, for matching
317 IPv6 fields, which was not a priority at the time. Lack of room to sup‐
318 port matching the Ethernet addresses inside ARP packets actually caused
319 more of a design problem later, leading to an Open vSwitch extension
320 action specialized for dropping ``spoofed’’ ARP packets in which the
321 frame and ARP Ethernet source addressed differed. (This extension was
322 never standardized. Open vSwitch dropped support for it a few releases
323 after it added support for full ARP matching.)
324 The design of the OpenFlow fixed-length matches also illustrates com‐
326 promises, in both directions, between the strengths and weaknesses of
327 software and hardware that have always influenced the design of Open‐
328 Flow. Support for matching ARP fields that do fit in the data structure
329 was only added late in the design process (and remained optional in
330 OpenFlow 1.0), for example, because common switch ASICs did not support
331 matching these fields.
332 The compromises in favor of software occurred for more complicated rea‐
334 sons. The OpenFlow designers did not know how to implement matching in
335 software that was fast, dynamic, and general. (A way was later found
336 [Srinivasan].) Thus, the designers sought to support dynamic, general
337 matching that would be fast in realistic special cases, in particular
338 when all of the matches were microflows, that is, matches that specify
339 every field present in a packet, because such matches can be imple‐
340 mented as a single hash table lookup. Contemporary research supported
341 the feasibility of this approach: the number of microflows in a campus
342 network had been measured to peak at about 10,000 [Casado, section
343 3.2]. (Calculations show that this can only be true in a lightly loaded
344 network [Pepelnjak].)
345 As a result, OpenFlow 1.0 required switches to treat microflow matches
347 as the highest possible priority. This let software switches perform
348 the microflow hash table lookup first. Only on failure to match a
349 microflow did the switch need to fall back to checking the more general
350 and presumed slower matches. Also, the OpenFlow 1.0 flow match was min‐
351 imally flexible, with no support for general bitwise matching, partly
352 on the basis that this seemed more likely amenable to relatively effi‐
353 cient software implementation. (CIDR masking for IPv4 addresses was
354 added relatively late in the OpenFlow 1.0 design process.)
355 Microflow matching was later discovered to aid some hardware implemen‐
357 tations. The TCAM chips used for matching in hardware do not support
358 priority in the same way as OpenFlow but instead tie priority to order‐
359 ing [Pagiamtzis]. Thus, adding a new match with a priority between the
360 priorities of existing matches can require reordering an arbitrary num‐
361 ber of TCAM entries. On the other hand, when microflows are highest
362 priority, they can be managed as a set-aside portion of the TCAM
363 entries.
364 The emphasis on matching microflows also led designers to carefully
366 consider the bandwidth requirements between switch and controller: to
367 maximize the number of microflow setups per second, one must minimize
368 the size of each flow’s description. This favored the fixed-length for‐
369 mat in use, because it expressed common TCP and UDP microflows in fewer
370 bytes than more flexible ``type-length-value’’ (TLV) formats. (Early
371 versions of OpenFlow also avoided TLVs in general to head off protocol
372 fragmentation.)
373 Inapplicable Fields
375 OpenFlow 1.0 does not clearly specify how to treat inapplicable fields.
377 The members for inapplicable fields are always present in the match
378 data structure, as are the bits that indicate whether the fields are
379 matched, and the ``correct’’ member and bit values for inapplicable
380 fields is unclear. OpenFlow 1.0 implementations changed their behavior
381 over time as priorities shifted. The early OpenFlow reference implemen‐
382 tation, motivated to make every flow a microflow to enable hashing,
383 treated inapplicable fields as exact matches on a value of 0. Ini‐
384 tially, this behavior was implemented in the reference controller only.
385 Later, the reference switch was also changed to actually force any
387 wildcarded inapplicable fields into exact matches on 0. The latter
388 behavior sometimes caused problems, because the modified flow was the
389 one reported back to the controller later when it queried the flow ta‐
390 ble, and the modifications sometimes meant that the controller could
391 not properly recognize the flow that it had added. In retrospect, per‐
392 haps this problem should have alerted the designers to a design error,
393 but the ability to use a single hash table was held to be more impor‐
394 tant than almost every other consideration at the time.
395 When more flexible match formats were introduced much later, they dis‐
397 allowed any mention of inapplicable fields as part of a match. This
398 raised the question of how to translate between this new format and the
399 OpenFlow 1.0 fixed format. It seemed somewhat inconsistent and backward
400 to treat fields as exact-match in one format and forbid matching them
401 in the other, so instead the treatment of inapplicable fields in the
402 fixed-length format was changed from exact match on 0 to wildcarding.
403 (A better classifier had by now eliminated software performance prob‐
404 lems with wildcards.)
405 The OpenFlow 1.0.1 errata (released only in 2012) added some additional
407 explanation [OpenFlow 1.0.1, section 3.4], but it did not mandate spe‐
408 cific behavior because of variation among implementations.
409 OpenFlow 1.1
411 The OpenFlow 1.1 protocol match format was designed as a
413 type/length/value (TLV) format to allow for future flexibility. The
414 specification standardized only a single type OFPMT_STANDARD (0) with a
415 fixed-size payload, described here. The additional fields and bitwise
416 masks in OpenFlow 1.1 cause this match structure to be over twice as
417 large as in OpenFlow 1.0, 88 bytes versus 40.
418 OpenFlow 1.1 added support for the following fields:
420 · SCTP source and destination port.
422 · MPLS label and traffic control (TC) fields.
424 · One 64-bit register (named ``metadata’’).
426 OpenFlow 1.1 increased the width of the ingress port number field (and
428 all other port numbers in the protocol) from 16 bits to 32 bits.
429 OpenFlow 1.1 increased matching flexibility by introducing arbitrary
431 bitwise matching on Ethernet and IPv4 address fields and on the new
432 ``metadata’’ register field. Switches were not required to support all
433 possible masks [OpenFlow 1.1, section 4.3].
434 By a strict reading of the specification, OpenFlow 1.1 removed support
436 for matching ICMPv4 type and code [OpenFlow 1.1, section A.2.3], but
437 this is likely an editing error because ICMP matching is described
438 elsewhere [OpenFlow 1.1, Table 3, Table 4, Figure 4]. Open vSwitch does
439 support ICMPv4 type and code matching with OpenFlow 1.1.
440 OpenFlow 1.1 avoided the pitfalls of inapplicable fields that OpenFlow
442 1.0 encountered, by requiring the switch to ignore the specified field
443 values [OpenFlow 1.1, section A.2.3]. It also implied that the switch
444 should ignore the bits that indicate whether to match inapplicable
445 fields.
446 Physical Ingress Port
448 OpenFlow 1.1 introduced a new pseudo-field, the physical ingress port.
450 The physical ingress port is only a pseudo-field because it cannot be
451 used for matching. It appears only one place in the protocol, in the
452 ``packet-in’’ message that passes a packet received at the switch to an
453 OpenFlow controller.
454 A packet’s ingress port and physical ingress port are identical except
456 for packets processed by a switch feature such as bonding or tunneling
457 that makes a packet appear to arrive on a ``virtual’’ port associated
458 with the bond or the tunnel. For such packets, the ingress port is the
459 virtual port and the physical ingress port is, naturally, the physical
460 port. Open vSwitch implements both bonding and tunneling, but its bond‐
461 ing implementation does not use virtual ports and its tunnels are typi‐
462 cally not on the same OpenFlow switch as their physical ingress ports
463 (which need not be part of any switch), so the ingress port and physi‐
464 cal ingress port are always the same in Open vSwitch.
465 OpenFlow 1.2
467 OpenFlow 1.2 abandoned the fixed-length approach to matching. One rea‐
469 son was size, since adding support for IPv6 address matching (now seen
470 as important), with bitwise masks, would have added 64 bytes to the
471 match length, increasing it from 88 bytes in OpenFlow 1.1 to over 150
472 bytes. Extensibility had also become important as controller writers
473 increasingly wanted support for new fields without having to change
474 messages throughout the OpenFlow protocol. The challenges of carefully
475 defining fixed-length matches to avoid problems with inapplicable
476 fields had also become clear over time.
477 Therefore, OpenFlow 1.2 adopted a flow format using a flexible type-
479 length-value (TLV) representation, in which each TLV expresses a match
480 on one field. These TLVs were in turn encapsulated inside the outer TLV
481 wrapper introduced in OpenFlow 1.1 with the new identifier OFPMT_OXM
482 (1). (This wrapper fulfilled its intended purpose of reducing the
483 amount of churn in the protocol when changing match formats; some mes‐
484 sages that included matches remained unchanged from OpenFlow 1.1 to 1.2
485 and later versions.)
486 OpenFlow 1.2 added support for the following fields:
488 · ARP hardware addresses (SHA and THA).
490 · IPv4 ECN.
492 · IPv6 source and destination addresses, flow label, DSCP,
494 ECN, and protocol.
495 · TCP, UDP, and SCTP port numbers when encapsulated inside
497 IPv6.
498 · ICMPv6 type and code.
500 · ICMPv6 Neighbor Discovery target address and source and
502 target Ethernet addresses.
503 The OpenFlow 1.2 format, called OXM (OpenFlow Extensible Match), was
505 modeled closely on an extension to OpenFlow 1.0 introduced in Open
506 vSwitch 1.1 called NXM (Nicira Extended Match). Each OXM or NXM TLV has
507 the following format:
508 type
510 <---------------->
511 16 7 1 8 length bytes
512 +------------+-----+--+------+ +------------+
513 |vendor/class|field|HM|length| | body |
514 +------------+-----+--+------+ +------------+
515 The most significant 16 bits of the NXM or OXM header, called vendor by
518 NXM and class by OXM, identify an organization permitted to allocate
519 identifiers for fields. NXM allocates only two vendors, 0x0000 for
520 fields supported by OpenFlow 1.0 and 0x0001 for fields implemented as
521 an Open vSwitch extension. OXM assigns classes as follows:
522 0x0000 (OFPXMC_NXM_0).
524 0x0001 (OFPXMC_NXM_1).
525 Reserved for NXM compatibility.
526 0x0002 to 0x7fff
528 Reserved for allocation to ONF members, but none yet
529 assigned.
530 0x8000 (OFPXMC_OPENFLOW_BASIC)
532 Used for most standard OpenFlow fields.
533 0x8001 (OFPXMC_PACKET_REGS)
535 Used for packet register fields in OpenFlow 1.5 and later.
536 0x8002 to 0xfffe
538 Reserved for the OpenFlow specification.
539 0xffff (OFPXMC_EXPERIMENTER)
541 Experimental use.
542 When class is 0xffff, the OXM header is extended to 64 bits by using
544 the first 32 bits of the body as an experimenter field whose most sig‐
545 nificant byte is zero and whose remaining bytes are an Organizationally
546 Unique Identifier (OUI) assigned by the IEEE [IEEE OUI], as shown
547 below.
548 type experimenter
550 <----------> <---------->
551 16 7 1 8 8 24 (length - 4) bytes
552 +------+-----+--+------+ +------+-----+ +------------------+
553 |class |field|HM|length| | zero | OUI | | body |
554 +------+-----+--+------+ +------+-----+ +------------------+
555 0xffff 0x00
556 OpenFlow says that support for experimenter fields is optional. Open
559 vSwitch 2.4 and later does support them, so that it can support the
560 following experimenter classes:
561 0x4f4e4600 (ONFOXM_ET)
563 Used by official Open Networking Foundation extensions in
564 OpenFlow 1.3 and later. e.g. [TCP Flags Match Field
565 Extension].
566 0x005ad650 (NXOXM_NSH)
568 Used by Open vSwitch for NSH extensions, in the absence
569 of an official ONF-assigned class. (This OUI is randomly
570 generated.)
571 Taken as a unit, class (or vendor), field, and experimenter (when
573 present) uniquely identify a particular field.
574 When hasmask (abbreviated HM above) is 0, the OXM is an exact match on
576 an entire field. In this case, the body (excluding the experimenter
577 field, if present) is a single value to be matched.
578 When hasmask is 1, the OXM is a bitwise match. The body (excluding the
580 experimenter field) consists of a value to match, followed by the bit‐
581 wise mask to apply. A 1-bit in the mask indicates that the correspond‐
582 ing bit in the value should be matched and a 0-bit that it should be
583 ignored. For example, for an IP address field, a value of 192.168.0.0
584 followed by a mask of 255.255.0.0 would match addresses in the
585 196.168.0.0/16 subnet.
586 · Some fields might not support masking at all, and some
588 fields that do support masking might restrict it to cer‐
589 tain patterns. For example, fields that have IP address
590 values might be restricted to CIDR masks. The descrip‐
591 tions of individual fields note these restrictions.
592 · An OXM TLV with a mask that is all zeros is not useful
594 (although it is not forbidden), because it is has the
595 same effect as omitting the TLV entirely.
596 · It is not meaningful to pair a 0-bit in an OXM mask with
598 a 1-bit in its value, and Open vSwitch rejects such an
599 OXM with the error OFPBMC_BAD_WILDCARDS, as required by
600 OpenFlow 1.3 and later.
601 The length identifies the number of bytes in the body, including the
603 4-byte experimenter header, if it is present. Each OXM TLV has a fixed
604 length; that is, given class, field, experimenter (if present), and
605 hasmask, length is a constant. The length is included explicitly to
606 allow software to minimally parse OXM TLVs of unknown types.
607 OXM TLVs must be ordered so that a field’s prerequisites are satisfied
609 before it is parsed. For example, an OXM TLV that matches on the IPv4
610 source address field is only allowed following an OXM TLV that matches
611 on the Ethertype for IPv4. Similarly, an OXM TLV that matches on the
612 TCP source port must follow a TLV that matches an Ethertype of IPv4 or
613 IPv6 and one that matches an IP protocol of TCP (in that order). The
614 order of OXM TLVs is not otherwise restricted; no canonical ordering is
615 defined.
616 A given field may be matched only once in a series of OXM TLVs.
618 OpenFlow 1.3
620 OpenFlow 1.3 showed OXM to be largely successful, by adding new fields
622 without making any changes to how flow matches otherwise worked. It
623 added OXMs for the following fields supported by Open vSwitch:
624 · Tunnel ID for ports associated with e.g. VXLAN or keyed
626 GRE.
627 · MPLS ``bottom of stack’’ (BOS) bit.
629 OpenFlow 1.3 also added OXMs for the following fields not documented
631 here and not yet implemented by Open vSwitch:
632 · IPv6 extension header handling.
634 · PBB I-SID.
636 OpenFlow 1.4
638 OpenFlow 1.4 added OXMs for the following fields not documented here
640 and not yet implemented by Open vSwitch:
641 · PBB UCA.
643 OpenFlow 1.5
645 OpenFlow 1.5 added OXMs for the following fields supported by Open
647 vSwitch:
648 · Packet type.
650 · TCP flags.
652 · Packet registers.
654 · The output port in the OpenFlow action set.
656
658 The following sections document the fields that Open vSwitch supports.
659 Each section provides introductory material on a group of related
660 fields, followed by information on each individual field. In addition
661 to field-specific information, each field begins with a table with
662 entries for the following important properties:
663 Name The field’s name, used for parsing and formatting the
665 field, e.g. in ovs-ofctl commands. For historical rea‐
666 sons, some fields have an additional name that is
667 accepted as an alternative in parsing. This name, when
668 there is one, is listed as well, e.g. ``tun (aka tun‐
669 nel_id).’’
670 Width The field’s width, always a multiple of 8 bits. Some
672 fields don’t use all of the bits, so this may be accompa‐
673 nied by an explanation. For example, OpenFlow embeds the
674 2-bit IP ECN field as as the low bits in an 8-bit byte,
675 and so its width is expressed as ``8 bits (only the
676 least-significant 2 bits may be nonzero).’’
677 Format How a value for the field is formatted or parsed by,
679 e.g., ovs-ofctl. Some possibilities are generic:
680 decimal
682 Formats as a decimal number. On input, accepts
683 decimal numbers or hexadecimal numbers prefixed by
684 0x.
685 hexadecimal
687 Formats as a hexadecimal number prefixed by 0x. On
688 input, accepts decimal numbers or hexadecimal num‐
689 bers prefixed by 0x. (The default for parsing is
690 not hexadecimal: only a 0x prefix causes input to
691 be treated as hexadecimal.)
692 Ethernet
694 Formats and accepts the common Ethernet address
695 format xx:xx:xx:xx:xx:xx.
696 IPv4 Formats and accepts the dotted-quad format
698 a.b.c.d. For bitwise matches, formats and accepts
699 address/length CIDR notation in addition to
700 address/mask.
701 IPv6 Formats and accepts the common IPv6 address for‐
703 mats, plus CIDR notation for bitwise matches.
704 OpenFlow 1.0 port
706 Accepts 16-bit port numbers in decimal, plus Open‐
707 Flow well-known port names (e.g. IN_PORT) in
708 uppercase or lowercase.
709 OpenFlow 1.1+ port
711 Same syntax as OpenFlow 1.0 ports but for 32-bit
712 OpenFlow 1.1+ port number fields.
713 Other, field-specific formats are explained along with
715 their fields.
716 Masking
718 For most fields, this says ``arbitrary bitwise masks,’’
719 meaning that a flow may match any combination of bits in
720 the field. Some fields instead say ``exact match only,’’
721 which means that a flow that matches on this field must
722 match on the whole field instead of just certain bits.
723 Either way, this reports masking support for the latest
724 version of Open vSwitch using OXM or NXM (that is, either
725 OpenFlow 1.2+ or OpenFlow 1.0 plus Open vSwitch NXM
726 extensions). In particular, OpenFlow 1.0 (without NXM)
727 and 1.1 don’t always support masking even if Open vSwitch
728 itself does; refer to the OpenFlow 1.0 and OpenFlow 1.1
729 rows to learn about masking with these protocol versions.
730 Prerequisites
732 Requirements that must be met to match on this field. For
733 example, ip_src has IPv4 as a prerequisite, meaning that
734 a match must include eth_type=0x0800 to match on the IPv4
735 source address. The following prerequisites, with their
736 requirements, are currently in use:
737 none (no requirements)
739 VLAN VID
741 vlan_tci=0x1000/0x1000 (i.e. a VLAN header is
742 present)
743 ARP eth_type=0x0806 (ARP) or eth_type=0x8035 (RARP)
745 IPv4 eth_type=0x0800
747 IPv6 eth_type=0x86dd
749 IPv4/IPv6
751 IPv4 or IPv6
752 MPLS eth_type=0x8847 or eth_type=0x8848
754 TCP IPv4/IPv6 and ip_proto=6
756 UDP IPv4/IPv6 and ip_proto=17
758 SCTP IPv4/IPv6 and ip_proto=132
760 ICMPv4 IPv4 and ip_proto=1
762 ICMPv6 IPv6 and ip_proto=58
764 ND solicit
766 ICMPv6 and icmp_type=135 and icmp_code=0
767 ND advert
769 ICMPv6 and icmp_type=136 and icmp_code=0
770 ND ND solicit or ND advert
772 The TCP, UDP, and SCTP prerequisites also have the spe‐
774 cial requirement that nw_frag is not being used to select
775 ``later fragments.’’ This is because only the first frag‐
776 ment of a fragmented IPv4 or IPv6 datagram contains the
777 TCP or UDP header.
778 Access Most fields are ``read/write,’’ which means that common
780 OpenFlow actions like set_field can modify them. Fields
781 that are ``read-only’’ cannot be modified in these gen‐
782 eral-purpose ways, although there may be other ways that
783 actions can modify them.
784 OpenFlow 1.0
786 OpenFlow 1.1
787 These rows report the level of support that OpenFlow 1.0 or
788 OpenFlow 1.1, respectively, has for a field. For OpenFlow
789 1.0, supported fields are reported as either ``yes (exact
790 match only)’’ for fields that do not support any bitwise
791 masking or ``yes (CIDR match only)’’ for fields that sup‐
792 port CIDR masking. OpenFlow 1.1 supported fields report
793 either ``yes (exact match only)’’ or simply ``yes’’ for
794 fields that do support arbitrary masks. These OpenFlow ver‐
795 sions supported a fixed collection of fields that cannot be
796 extended, so many more fields are reported as ``not sup‐
797 ported.’’
798 OXM
800 NXM These rows report the OXM and NXM code points that corre‐
801 spond to a given field. Either or both may be ``none.’’
802 A field that has only an OXM code point is usually one that
804 was standardized before it was added to Open vSwitch. A
805 field that has only an NXM code point is usually one that
806 is not yet standardized. When a field has both OXM and NXM
807 code points, it usually indicates that it was introduced as
808 an Open vSwitch extension under the NXM code point, then
809 later standardized under the OXM code point. A field can
810 have more than one OXM code point if it was standardized in
811 OpenFlow 1.4 or later and additionally introduced as an
812 official ONF extension for OpenFlow 1.3. (A field that has
813 neither OXM nor NXM code point is typically an obsolete
814 field that is supported in some other form using OXM or
815 NXM.)
816 Each code point in these rows is described in the form
818 ``NAME (number) since OpenFlow spec and Open vSwitch ver‐
819 sion,’’ e.g. ``OXM_OF_ETH_TYPE (5) since OpenFlow 1.2 and
820 Open vSwitch 1.7.’’ First, NAME, which specifies a name for
821 the code point, starts with a prefix that designates a
822 class and, in some cases, a vendor, as listed in the fol‐
823 lowing table:
824 Prefix Vendor Class
826 ─────────────── ─────────── ───────
827 NXM_OF (none) 0x0000
828 NXM_NX (none) 0x0001
829 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
840 because 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
855 address 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
884 example, but it does not gracefully extend to larger sets or greater
885 numbers 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
948 actions within a list of actions is not significant.
949 · A flow with conjunction actions may also include note
951 actions for annotations, but not any other kind of
952 actions. (They would not be useful because they would
953 never be executed.)
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
968 results.
969 · Following a conjunctive flow match, the search for the
971 flow with conj_id=id is done in the same general-purpose
972 way as other flow table searches, so one can use flows
973 with conj_id=id to act differently depending on circum‐
974 stances. (One exception is that the search for the
975 conj_id=id flow itself ignores conjunctive flows, to
976 avoid recursion.) If the search with conj_id=id fails,
977 Open vSwitch acts as if the conjunctive flow had not
978 matched at all, and continues searching the flow table
979 for other matching flows.
980 · OpenFlow prerequisite checking occurs for the flow with
982 conj_id=id in the same way as any other flow, e.g. in an
983 OpenFlow 1.1+ context, putting a mod_nw_src action into
984 the example above would require adding an ip match, like
985 this:
986 conj_id=1234,ip actions=mod_nw_src:1.2.3.4,controller
988 · OpenFlow prerequisite checking also occurs for the indi‐
991 vidual flows that comprise a conjunctive match in the
992 same way as any other flow.
993 · The flows that constitute a conjunctive flow do not have
995 useful statistics. They are never updated with byte or
996 packet counts, and so on. (For such a flow, therefore,
997 the idle and hard timeouts work much the same way.)
998 · Sometimes there is a choice of which flows include a par‐
1000 ticular match. For example, suppose that we added an
1001 extra constraint to our example, to match on ip_src ∈
1002 {a,b,c,d} and ip_dst ∈ {e,f,g,h} and tcp_dst = i. One way
1003 to implement this is to add the new constraint to the
1004 conj_id flow, like this:
1005 conj_id=1234,tcp,tcp_dst=i actions=mod_nw_src:1.2.3.4,controller
1007 but this is not recommended because of the cost of the
1010 extra flow table lookup. Instead, add the constraint to
1011 the individual flows, either in one of the dimensions or
1012 (slightly better) all of them.
1013 · A conjunctive match must have n ≥ 2 dimensions (otherwise
1015 a conjunctive match is not necessary). Open vSwitch
1016 enforces this.
1017 · Each dimension within a conjunctive match should ordinar‐
1019 ily have more than one flow. Open vSwitch does not
1020 enforce this.
1021 Conjunction ID Field
1023 Name: conj_id
1025 Width: 32 bits
1026 Format: decimal
1027 Masking: not maskable
1028 Prerequisites: none
1029 Access: read-only
1030 OpenFlow 1.0: not supported
1031 OpenFlow 1.1: not supported
1032 OXM: none
1033 NXM: NXM_NX_CONJ_ID (37) since Open vSwitch 2.4
1034 Used for conjunctive matching. See above for more information.
1036
1038 Summary:
1039 Name Bytes Mask RW? Prereqs NXM/OXM Support
1040 ───────────────────── ──────────────── ───── ──── ──────── ─────────────────────
1041 tun_id aka tunnel_id 8 yes yes none OF 1.3+ and OVS 1.1+
1042 tun_src 4 yes yes none OVS 2.0+
1043 tun_dst 4 yes yes none OVS 2.0+
1044 tun_ipv6_src 16 yes yes none OVS 2.5+
1045 tun_ipv6_dst 16 yes yes none OVS 2.5+
1046 tun_gbp_id 2 yes yes none OVS 2.4+
1047 tun_gbp_flags 1 yes yes none OVS 2.4+
1048 tun_erspan_ver 1 (low 4 bits) yes yes none OVS 2.10+
1049 tun_erspan_idx 4 (low 20 bits) yes yes none OVS 2.10+
1050 tun_erspan_dir 1 (low 1 bits) yes yes none OVS 2.10+
1051 tun_erspan_hwid 1 (low 6 bits) yes yes none OVS 2.10+
1052 tun_metadata0 124 yes yes none OVS 2.5+
1053 tun_metadata1 124 yes yes none OVS 2.5+
1055 tun_metadata2 124 yes yes none OVS 2.5+
1056 tun_metadata3 124 yes yes none OVS 2.5+
1057 tun_metadata4 124 yes yes none OVS 2.5+
1058 tun_metadata5 124 yes yes none OVS 2.5+
1059 tun_metadata6 124 yes yes none OVS 2.5+
1060 tun_metadata7 124 yes yes none OVS 2.5+
1061 tun_metadata8 124 yes yes none OVS 2.5+
1062 tun_metadata9 124 yes yes none OVS 2.5+
1063 tun_metadata10 124 yes yes none OVS 2.5+
1064 tun_metadata11 124 yes yes none OVS 2.5+
1065 tun_metadata12 124 yes yes none OVS 2.5+
1066 tun_metadata13 124 yes yes none OVS 2.5+
1067 tun_metadata14 124 yes yes none OVS 2.5+
1068 tun_metadata15 124 yes yes none OVS 2.5+
1069 tun_metadata16 124 yes yes none OVS 2.5+
1070 tun_metadata17 124 yes yes none OVS 2.5+
1071 tun_metadata18 124 yes yes none OVS 2.5+
1073 tun_metadata19 124 yes yes none OVS 2.5+
1074 tun_metadata20 124 yes yes none OVS 2.5+
1075 tun_metadata21 124 yes yes none OVS 2.5+
1076 tun_metadata22 124 yes yes none OVS 2.5+
1077 tun_metadata23 124 yes yes none OVS 2.5+
1078 tun_metadata24 124 yes yes none OVS 2.5+
1079 tun_metadata25 124 yes yes none OVS 2.5+
1080 tun_metadata26 124 yes yes none OVS 2.5+
1081 tun_metadata27 124 yes yes none OVS 2.5+
1082 tun_metadata28 124 yes yes none OVS 2.5+
1083 tun_metadata29 124 yes yes none OVS 2.5+
1084 tun_metadata30 124 yes yes none OVS 2.5+
1085 tun_metadata31 124 yes yes none OVS 2.5+
1086 tun_metadata32 124 yes yes none OVS 2.5+
1087 tun_metadata33 124 yes yes none OVS 2.5+
1088 tun_metadata34 124 yes yes none OVS 2.5+
1089 tun_metadata35 124 yes yes none OVS 2.5+
1091 tun_metadata36 124 yes yes none OVS 2.5+
1092 tun_metadata37 124 yes yes none OVS 2.5+
1093 tun_metadata38 124 yes yes none OVS 2.5+
1094 tun_metadata39 124 yes yes none OVS 2.5+
1095 tun_metadata40 124 yes yes none OVS 2.5+
1096 tun_metadata41 124 yes yes none OVS 2.5+
1097 tun_metadata42 124 yes yes none OVS 2.5+
1098 tun_metadata43 124 yes yes none OVS 2.5+
1099 tun_metadata44 124 yes yes none OVS 2.5+
1100 tun_metadata45 124 yes yes none OVS 2.5+
1101 tun_metadata46 124 yes yes none OVS 2.5+
1102 tun_metadata47 124 yes yes none OVS 2.5+
1103 tun_metadata48 124 yes yes none OVS 2.5+
1104 tun_metadata49 124 yes yes none OVS 2.5+
1105 tun_metadata50 124 yes yes none OVS 2.5+
1106 tun_metadata51 124 yes yes none OVS 2.5+
1107 tun_metadata52 124 yes yes none OVS 2.5+
1109 tun_metadata53 124 yes yes none OVS 2.5+
1110 tun_metadata54 124 yes yes none OVS 2.5+
1111 tun_metadata55 124 yes yes none OVS 2.5+
1112 tun_metadata56 124 yes yes none OVS 2.5+
1113 tun_metadata57 124 yes yes none OVS 2.5+
1114 tun_metadata58 124 yes yes none OVS 2.5+
1115 tun_metadata59 124 yes yes none OVS 2.5+
1116 tun_metadata60 124 yes yes none OVS 2.5+
1117 tun_metadata61 124 yes yes none OVS 2.5+
1118 tun_metadata62 124 yes yes none OVS 2.5+
1119 tun_metadata63 124 yes yes none OVS 2.5+
1120 tun_flags 2 (low 1 bits) yes yes none OVS 2.5+
1121 The fields in this group relate to tunnels, which Open vSwitch supports
1123 in several forms (GRE, VXLAN, and so on). Most of these fields do
1124 appear in the wire format of a packet, so they are data fields from
1125 that point of view, but they are metadata from an OpenFlow flow table
1126 point of view because they do not appear in packets that are forwarded
1127 to the controller or to ordinary (non-tunnel) output ports.
1128 Open vSwitch supports a spectrum of usage models for mapping tunnels to
1130 OpenFlow ports:
1131 ``Port-based’’ tunnels
1133 In this model, an OpenFlow port represents one tunnel: it
1134 matches a particular type of tunnel traffic between two
1135 IP endpoints, with a particular tunnel key (if keys are
1136 in use). In this situation, in_port suffices to distin‐
1137 guish one tunnel from another, so the tunnel header
1138 fields have little importance for OpenFlow processing.
1139 (They are still populated and may be used if it is conve‐
1140 nient.) The tunnel header fields play no role in sending
1141 packets out such an OpenFlow port, either, because the
1142 OpenFlow port itself fully specifies the tunnel headers.
1143 The following Open vSwitch commands create a bridge
1145 br-int, add port tap0 to the bridge as OpenFlow port 1,
1146 establish a port-based GRE tunnel between the local host
1147 and remote IP 192.168.1.1 using GRE key 5001 as OpenFlow
1148 port 2, and arranges to forward all traffic from tap0 to
1149 the tunnel and vice versa:
1150 ovs-vsctl add-br br-int
1152 ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1153 ovs-vsctl add-port br-int gre0 --
1154 set interface gre0 ofport_request=2 type=gre \
1155 options:remote_ip=192.168.1.1 options:key=5001
1156 ovs-ofctl add-flow br-int in_port=1,actions=2
1157 ovs-ofctl add-flow br-int in_port=2,actions=1
1158 ``Flow-based’’ tunnels
1161 In this model, one OpenFlow port represents all possible
1162 tunnels of a given type with an endpoint on the current
1163 host, for example, all GRE tunnels. In this situation,
1164 in_port only indicates that traffic was received on the
1165 particular kind of tunnel. This is where the tunnel
1166 header fields are most important: they allow the OpenFlow
1167 tables to discriminate among tunnels based on their IP
1168 endpoints or keys. Tunnel header fields also determine
1169 the IP endpoints and keys of packets sent out such a tun‐
1170 nel port.
1171 The following Open vSwitch commands create a bridge
1173 br-int, add port tap0 to the bridge as OpenFlow port 1,
1174 establish a flow-based GRE tunnel port 3, and arranges to
1175 forward all traffic from tap0 to remote IP 192.168.1.1
1176 over a GRE tunnel with key 5001 and vice versa:
1177 ovs-vsctl add-br br-int
1179 ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1180 ovs-vsctl add-port br-int allgre --
1181 set interface gre0 ofport_request=3 type=gre \
1182 options:remote_ip=flow options:key=flow
1183 ovs-ofctl add-flow br-int \
1184 ’in_port=1 actions=set_tunnel:5001,set_field:192.168.1.1->tun_dst,3’
1185 ovs-ofctl add-flow br-int ’in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1’
1186 Mixed models.
1189 One may define both flow-based and port-based tunnels at
1190 the same time. For example, it is valid and possibly use‐
1191 ful to create and configure both gre0 and allgre tunnel
1192 ports described above.
1193 Traffic is attributed on ingress to the most specific
1195 matching tunnel. For example, gre0 is more specific than
1196 allgre. Therefore, if both exist, then gre0 will be the
1197 ingress port for any GRE traffic received from
1198 192.168.1.1 with key 5001.
1199 On egress, traffic may be directed to any appropriate
1201 tunnel port. If both gre0 and allgre are configured as
1202 already described, then the actions 2 and set_tun‐
1203 nel:5001,set_field:192.168.1.1->tun_dst,3 send the same
1204 tunnel traffic.
1205 Intermediate models.
1207 Ports may be configured as partially flow-based. For
1208 example, one may define an OpenFlow port that represents
1209 tunnels between a pair of endpoints but leaves the flow
1210 table to discriminate on the flow key.
1211 ovs-vswitchd.conf.db(5) describes all the details of tunnel configura‐
1213 tion.
1214 These fields do not have any prerequisites, which means that a flow may
1216 match on any or all of them, in any combination.
1217 These fields are zeros for packets that did not arrive on a tunnel.
1219 Tunnel ID Field
1221 Name: tun_id (aka tunnel_id)
1223 Width: 64 bits
1224 Format: hexadecimal
1225 Masking: arbitrary bitwise masks
1226 Prerequisites: none
1227 Access: read/write
1228 OpenFlow 1.0: not supported
1229 OpenFlow 1.1: not supported
1230 OXM: OXM_OF_TUNNEL_ID [22m(38) since OpenFlow 1.3 and Open
1231 vSwitch 1.10
1232 NXM: NXM_NX_TUN_ID (16) since Open vSwitch 1.1
1233 Many kinds of tunnels support a tunnel ID:
1235 · VXLAN and Geneve have a 24-bit virtual network identifier
1237 (VNI).
1238 · LISP has a 24-bit instance ID.
1240 · GRE has an optional 32-bit key.
1242 · STT has a 64-bit key.
1244 · ERSPAN has a 10-bit key (Session ID).
1246 When a packet is received from a tunnel, this field holds the tunnel ID
1248 in its least significant bits, zero-extended to fit. This field is zero
1249 if the tunnel does not support an ID, or if no ID is in use for a tun‐
1250 nel type that has an optional ID, or if an ID of zero received, or if
1251 the packet was not received over a tunnel.
1252 When a packet is output to a tunnel port, the tunnel configuration
1254 determines whether the tunnel ID is taken from this field or bound to a
1255 fixed value. See the earlier description of ``port-based’’ and ``flow-
1256 based’’ tunnels for more information.
1257 The following diagram shows the origin of this field in a typical keyed
1259 GRE tunnel:
1260 Ethernet IPv4 GRE Ethernet
1262 <-----------> <---------------> <------------> <---------->
1263 48 48 16 8 32 32 16 16 32 48 48 16
1264 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1265 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1266 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1267 0x800 47 0x6558
1268 Tunnel IPv4 Source Field
1271 Name: tun_src
1273 Width: 32 bits
1274 Format: IPv4
1275 Masking: arbitrary bitwise masks
1276 Prerequisites: none
1277 Access: read/write
1278 OpenFlow 1.0: not supported
1279 OpenFlow 1.1: not supported
1280 OXM: none
1281 NXM: NXM_NX_TUN_IPV4_SRC (31) since Open vSwitch 2.0
1282 When a packet is received from a tunnel, this field is the source
1284 address in the outer IP header of the tunneled packet. This field is
1285 zero if the packet was not received over a tunnel.
1286 When a packet is output to a flow-based tunnel port, this field influ‐
1288 ences the IPv4 source address used to send the packet. If it is zero,
1289 then the kernel chooses an appropriate IP address based using the rout‐
1290 ing table.
1291 The following diagram shows the origin of this field in a typical keyed
1293 GRE tunnel:
1294 Ethernet IPv4 GRE Ethernet
1296 <-----------> <---------------> <------------> <---------->
1297 48 48 16 8 32 32 16 16 32 48 48 16
1298 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1299 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1300 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1301 0x800 47 0x6558
1302 Tunnel IPv4 Destination Field
1305 Name: tun_dst
1307 Width: 32 bits
1308 Format: IPv4
1309 Masking: arbitrary bitwise masks
1310 Prerequisites: none
1311 Access: read/write
1312 OpenFlow 1.0: not supported
1313 OpenFlow 1.1: not supported
1314 OXM: none
1315 NXM: NXM_NX_TUN_IPV4_DST (32) since Open vSwitch 2.0
1316 When a packet is received from a tunnel, this field is the destination
1318 address in the outer IP header of the tunneled packet. This field is
1319 zero if the packet was not received over a tunnel.
1320 When a packet is output to a flow-based tunnel port, this field speci‐
1322 fies the destination to which the tunnel packet is sent.
1323 The following diagram shows the origin of this field in a typical keyed
1325 GRE tunnel:
1326 Ethernet IPv4 GRE Ethernet
1328 <-----------> <---------------> <------------> <---------->
1329 48 48 16 8 32 32 16 16 32 48 48 16
1330 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1331 |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1332 +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1333 0x800 47 0x6558
1334 Tunnel IPv6 Source Field
1337 Name: tun_ipv6_src
1339 Width: 128 bits
1340 Format: IPv6
1341 Masking: arbitrary bitwise masks
1342 Prerequisites: none
1343 Access: read/write
1344 OpenFlow 1.0: not supported
1345 OpenFlow 1.1: not supported
1346 OXM: none
1347 NXM: NXM_NX_TUN_IPV6_SRC (109) since Open vSwitch 2.5
1349 Similar to tun_src, but for tunnels over IPv6.
1351 Tunnel IPv6 Destination Field
1353 Name: tun_ipv6_dst
1355 Width: 128 bits
1356 Format: IPv6
1357 Masking: arbitrary bitwise masks
1358 Prerequisites: none
1359 Access: read/write
1360 OpenFlow 1.0: not supported
1361 OpenFlow 1.1: not supported
1362 OXM: none
1363 NXM: NXM_NX_TUN_IPV6_DST (110) since Open vSwitch 2.5
1364 Similar to tun_dst, but for tunnels over IPv6.
1366 VXLAN Group-Based Policy Fields
1368 The VXLAN header is defined as follows [RFC 7348], where the I bit must
1369 be set to 1, unlabeled bits or those labeled reserved must be set to 0,
1370 and Open vSwitch makes the VNI available via tun_id:
1371 VXLAN flags
1373 <------------->
1374 1 1 1 1 1 1 1 1 24 24 8
1375 +-+-+-+-+-+-+-+-+--------+---+--------+
1376 | | | | |I| | | |reserved|VNI|reserved|
1377 +-+-+-+-+-+-+-+-+--------+---+--------+
1378 VXLAN Group-Based Policy [VXLAN Group Policy Option] adds new interpre‐
1381 tations to existing bits in the VXLAN header, reinterpreting it as fol‐
1382 lows, with changes highlighted:
1383 GBP flags
1385 <------------->
1386 1 1 1 1 1 1 1 1 24 24 8
1387 +-+-+-+-+-+-+-+-+---------------+---+--------+
1388 | |D| | |A| | | |group policy ID|VNI|reserved|
1389 +-+-+-+-+-+-+-+-+---------------+---+--------+
1390 Open vSwitch makes GBP fields and flags available through the following
1393 fields. Only packets that arrive over a VXLAN tunnel with the GBP
1394 extension enabled have these fields set. In other packets they are zero
1395 on receive and ignored on transmit.
1396 VXLAN Group-Based Policy ID Field
1398 Name: tun_gbp_id
1400 Width: 16 bits
1401 Format: decimal
1402 Masking: arbitrary bitwise masks
1403 Prerequisites: none
1404 Access: read/write
1405 OpenFlow 1.0: not supported
1406 OpenFlow 1.1: not supported
1407 OXM: none
1408 NXM: NXM_NX_TUN_GBP_ID (38) since Open vSwitch 2.4
1409 For a packet tunneled over VXLAN with the Group-Based Policy (GBP)
1411 extension, this field represents the GBP policy ID, as shown above.
1412 VXLAN Group-Based Policy Flags Field
1414 Name: tun_gbp_flags
1416 Width: 8 bits
1417 Format: hexadecimal
1418 Masking: arbitrary bitwise masks
1419 Prerequisites: none
1420 Access: read/write
1421 OpenFlow 1.0: not supported
1422 OpenFlow 1.1: not supported
1423 OXM: none
1424 NXM: NXM_NX_TUN_GBP_FLAGS (39) since Open vSwitch 2.4
1425 For a packet tunneled over VXLAN with the Group-Based Policy (GBP)
1427 extension, this field represents the GBP policy flags, as shown above.
1428 The field has the format shown below:
1430 GBP Flags
1432 <------------->
1433 1 1 1 1 1 1 1 1
1434 +-+-+-+-+-+-+-+-+
1435 | |D| | |A| | | |
1436 +-+-+-+-+-+-+-+-+
1437 Unlabeled bits are reserved and must be transmitted as 0. The VXLAN GBP
1440 draft defines the other bits’ meanings as:
1441 D (Don’t Learn)
1443 When set, this bit indicates that the egress tunnel end‐
1444 point must not learn the source address of the encapsu‐
1445 lated frame.
1446 A (Applied)
1448 When set, indicates that the group policy has already
1449 been applied to this packet. Devices must not apply poli‐
1450 cies when the A bit is set.
1451 ERSPAN Metadata Fields
1453 These fields provide access to features in the ERSPAN tunneling proto‐
1454 col [ERSPAN], which has two major versions: version 1 (aka type II) and
1455 version 2 (aka type III).
1456 Regardless of version, ERSPAN is encapsulated within a fixed 8-byte GRE
1458 header that consists of a 4-byte GRE base header and a 4-byte sequence
1459 number. The ERSPAN version 1 header format is:
1460 GRE ERSPAN v1 Ethernet
1462 <------------> <---------------------> <---------->
1463 16 16 32 4 18 10 12 20 48 48 16
1464 +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1465 |...| type |seq| |ver|...|session|...|idx| |dst|src|type| ...
1466 +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1467 0x88be 1 tun_id
1468 The ERSPAN version 2 header format is:
1471 GRE ERSPAN v2 Ethernet
1473 <------------> <----------------------------------------> <---------->
1474 16 16 32 4 18 10 32 22 6 1 3 48 48 16
1475 +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1476 |...| type |seq| |ver|...|session|timestamp|...|hwid|dir|...| |dst|src|type| ...
1477 +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1478 0x22eb 2 tun_id 0/1
1479 ERSPAN Version Field
1482 Name: tun_erspan_ver
1484 Width: 8 bits (only the least-significant 4 bits may be nonzero)
1485 Format: decimal
1486 Masking: arbitrary bitwise masks
1487 Prerequisites: none
1488 Access: read/write
1489 OpenFlow 1.0: not supported
1490 OpenFlow 1.1: not supported
1491 OXM: none
1492 NXM: NXOXM_ET_ERSPAN_VER (12) since Open vSwitch 2.10
1493 ERSPAN version number: 1 for version 1, or 2 for version 2.
1495 ERSPAN Index Field
1497 Name: tun_erspan_idx
1499 Width: 32 bits (only the least-significant 20 bits may be nonzero)
1500 Format: hexadecimal
1501 Masking: arbitrary bitwise masks
1503 Prerequisites: none
1504 Access: read/write
1505 OpenFlow 1.0: not supported
1506 OpenFlow 1.1: not supported
1507 OXM: none
1508 NXM: NXOXM_ET_ERSPAN_IDX (11) since Open vSwitch 2.10
1509 This field is a 20-bit index/port number associated with the ERSPAN
1511 traffic’s source port and direction (ingress/egress). This field is
1512 platform dependent.
1513 ERSPAN Direction Field
1515 Name: tun_erspan_dir
1517 Width: 8 bits (only the least-significant 1 bits may be nonzero)
1518 Format: decimal
1519 Masking: arbitrary bitwise masks
1520 Prerequisites: none
1521 Access: read/write
1522 OpenFlow 1.0: not supported
1523 OpenFlow 1.1: not supported
1525 OXM: none
1526 NXM: NXOXM_ET_ERSPAN_DIR (13) since Open vSwitch 2.10
1527 For ERSPAN v2, the mirrored traffic’s direction: 0 for ingress traffic,
1529 1 for egress traffic.
1530 ERSPAN Hardware ID Field
1532 Name: tun_erspan_hwid
1534 Width: 8 bits (only the least-significant 6 bits may be nonzero)
1535 Format: hexadecimal
1536 Masking: arbitrary bitwise masks
1537 Prerequisites: none
1538 Access: read/write
1539 OpenFlow 1.0: not supported
1540 OpenFlow 1.1: not supported
1541 OXM: none
1542 NXM: NXOXM_ET_ERSPAN_HWID (14) since Open vSwitch 2.10
1543 A 6-bit unique identifier of an ERSPAN v2 engine within a system.
1545 Geneve Fields
1547 These fields provide access to additional features in the Geneve tun‐
1548 neling protocol [Geneve]. Their names are somewhat generic in the hope
1549 that the same fields could be reused for other protocols in the future;
1550 for example, the NSH protocol [NSH] supports TLV options whose form is
1551 identical to that for Geneve options.
1552 Generic Tunnel Option 0 Field
1554 Name: tun_metadata0
1556 Width: 992 bits (124 bytes)
1557 Format: hexadecimal
1558 Masking: arbitrary bitwise masks
1559 Prerequisites: none
1560 Access: read/write
1561 OpenFlow 1.0: not supported
1562 OpenFlow 1.1: not supported
1563 OXM: none
1564 NXM: NXM_NX_TUN_METADATA0 (40) since Open vSwitch 2.5
1565 The above information specifically covers generic tunnel option 0, but
1567 Open vSwitch supports 64 options, numbered 0 through 63, whose NXM
1568 field numbers are 40 through 103.
1569 These fields provide OpenFlow access to the generic type-length-value
1571 options defined by the Geneve tunneling protocol or other protocols
1572 with options in the same TLV format as Geneve options. Each of these
1573 options has the following wire format:
1574 header body
1576 <-------------------> <------------------>
1577 16 8 3 5 4×(length - 1) bytes
1578 +-----+----+---+------+--------------------+
1579 |class|type|res|length| value |
1580 +-----+----+---+------+--------------------+
1581 0
1582 Taken together, the class and type in the option format mean that there
1585 are about 16 million distinct kinds of TLV options, too many to give
1586 individual OXM code points. Thus, Open vSwitch requires the user to
1587 define the TLV options of interest, by binding up to 64 TLV options to
1588 generic tunnel option NXM code points. Each option may have up to 124
1589 bytes in its body, the maximum allowed by the TLV format, but bound
1590 options may total at most 252 bytes of body.
1591 Open vSwitch extensions to the OpenFlow protocol bind TLV options to
1593 NXM code points. The ovs-ofctl(8) program offers one way to use these
1594 extensions, e.g. to configure a mapping from a TLV option with class
1595 0xffff, type 0, and a body length of 4 bytes:
1596 ovs-ofctl add-tlv-map br0 "{class=0xffff,type=0,len=4}->tun_metadata0"
1598 Once a TLV option is properly bound, it can be accessed and modified
1601 like any other field, e.g. to send packets that have value 1234 for the
1602 option described above to the controller:
1603 ovs-ofctl add-flow br0 tun_metadata0=1234,actions=controller
1605 An option not received or not bound is matched as all zeros.
1608 Tunnel Flags Field
1610 Name: tun_flags
1613 Width: 16 bits (only the least-significant 1 bits may be nonzero)
1614 Format: tunnel flags
1615 Masking: arbitrary bitwise masks
1616 Prerequisites: none
1617 Access: read/write
1618 OpenFlow 1.0: not supported
1619 OpenFlow 1.1: not supported
1620 OXM: none
1621 NXM: NXM_NX_TUN_FLAGS (104) since Open vSwitch 2.5
1622 Flags indicating various aspects of the tunnel encapsulation.
1624 Matches on this field are most conveniently written in terms of sym‐
1626 bolic names (given in the diagram below), each preceded by either + for
1627 a flag that must be set, or - for a flag that must be unset, without
1628 any other delimiters between the flags. Flags not mentioned are wild‐
1629 carded. For example, tun_flags=+oam matches only OAM packets. Matches
1630 can also be written as flags/mask, where flags and mask are 16-bit num‐
1631 bers in decimal or in hexadecimal prefixed by 0x.
1632 Currently, only one flag is defined:
1634 oam The tunnel protocol indicated that this is an OAM (Opera‐
1636 tions and Management) control packet.
1637 The switch may reject matches against unknown flags.
1639 Newer versions of Open vSwitch may introduce additional flags with new
1641 meanings. It is therefore not recommended to use an exact match on this
1642 field since the behavior of these new flags is unknown and should be
1643 ignored.
1644 For non-tunneled packets, the value is 0.
1646
1648 Summary:
1649 Name Bytes Mask RW? Prereqs NXM/OXM Support
1650 ────────────── ────── ───── ──── ──────── ─────────────────────
1651 in_port 2 no yes none OVS 1.1+
1652 in_port_oxm 4 no yes none OF 1.2+ and OVS 1.7+
1653 skb_priority 4 no no none
1654 pkt_mark 4 yes yes none OVS 2.0+
1655 actset_output 4 no no none OF 1.3+ and OVS 2.4+
1656 packet_type 4 no no none OF 1.5+ and OVS 2.8+
1657 These fields relate to the origin or treatment of a packet, but they
1659 are not extracted from the packet data itself.
1660 Ingress Port Field
1662 Name: in_port
1664 Width: 16 bits
1665 Format: OpenFlow 1.0 port
1666 Masking: not maskable
1667 Prerequisites: none
1668 Access: read/write
1669 OpenFlow 1.0: yes (exact match only)
1671 OpenFlow 1.1: yes (exact match only)
1672 OXM: none
1673 NXM: NXM_OF_IN_PORT (0) since Open vSwitch 1.1
1674 The OpenFlow port on which the packet being processed arrived. This is
1676 a 16-bit field that holds an OpenFlow 1.0 port number. For receiving a
1677 packet, the only values that appear in this field are:
1678 1 through 0xfeff (65,279), inclusive.
1680 Conventional OpenFlow port numbers.
1681 OFPP_LOCAL (0xfffe or 65,534).
1683 The ``local’’ port, which in Open vSwitch is always named
1684 the same as the bridge itself. This represents a connec‐
1685 tion between the switch and the local TCP/IP stack. This
1686 port is where an IP address is most commonly configured
1687 on an Open vSwitch switch.
1688 OpenFlow does not require a switch to have a local port,
1690 but all existing versions of Open vSwitch have always
1691 included a local port. Future Directions: Future versions
1692 of Open vSwitch might be able to optionally omit the
1693 local port, if someone submits code to implement such a
1694 feature.
1695 OFPP_NONE (OpenFlow 1.0) or OFPP_ANY (OpenFlow 1.1+) (0xffff or
1697 65,535).
1698 OFPP_CONTROLLER (0xfffd or 65,533).
1699 When a controller injects a packet into an OpenFlow switch
1700 with a ``packet-out’’ request, it can specify one of these
1701 ingress ports to indicate that the packet was generated
1702 internally rather than having been received on some port.
1703 OpenFlow 1.0 specified OFPP_NONE for this purpose. Despite
1705 that, some controllers used OFPP_CONTROLLER, and some
1706 switches only accepted OFPP_CONTROLLER, so OpenFlow 1.0.2
1707 required support for both ports. OpenFlow 1.1 and later
1708 were more clearly drafted to allow only OFPP_CONTROLLER.
1709 For maximum compatibility, Open vSwitch allows both ports
1710 with all OpenFlow versions.
1711 Values not mentioned above will never appear when receiving a packet,
1713 including the following notable values:
1714 0 Zero is not a valid OpenFlow port number.
1716 OFPP_MAX (0xff00 or 65,280).
1718 This value has only been clearly specified as a valid
1719 port number as of OpenFlow 1.3.3. Before that, its status
1720 was unclear, and so Open vSwitch has never allowed
1721 OFPP_MAX to be used as a port number, so packets will
1722 never be received on this port. (Other OpenFlow switches,
1723 of course, might use it.)
1724 OFPP_UNSET (0xfff7 or 65,527)
1726 OFPP_IN_PORT (0xfff8 or 65,528)
1727 OFPP_TABLE (0xfff9 or 65,529)
1728 OFPP_NORMAL (0xfffa or 65,530)
1729 OFPP_FLOOD (0xfffb or 65,531)
1730 OFPP_ALL (0xfffc or 65,532)
1731 These port numbers are used only in output actions and
1732 never appear as ingress ports.
1733 Most of these port numbers were defined in OpenFlow 1.0,
1735 but OFPP_UNSET was only introduced in OpenFlow 1.5.
1736 Values that will never appear when receiving a packet may still be
1738 matched against in the flow table. There are still circumstances in
1739 which those flows can be matched:
1740 · The resubmit Open vSwitch extension action allows a flow
1742 table lookup with an arbitrary ingress port.
1743 · An action that modifies the ingress port field (see
1745 below), such as e.g. load or set_field, followed by an
1746 action or instruction that performs another flow table
1747 lookup, such as resubmit or goto_table.
1748 This field is heavily used for matching in OpenFlow tables, but for
1750 packet egress, it has only very limited roles:
1751 · OpenFlow requires suppressing output actions to in_port.
1753 That is, the following two flows both drop all packets
1754 that arrive on port 1:
1755 in_port=1,actions=1
1757 in_port=1,actions=drop
1758 (This behavior is occasionally useful for flooding to a
1761 subset of ports. Specifying actions=1,2,3,4, for example,
1762 outputs to ports 1, 2, 3, and 4, omitting the ingress
1763 port.)
1764 · OpenFlow has a special port OFPP_IN_PORT (with value
1766 0xfff8) that outputs to the ingress port. For example, in
1767 a switch that has four ports numbered 1 through 4,
1768 actions=1,2,3,4,in_port outputs to ports 1, 2, 3, and 4,
1769 including the ingress port.
1770 Because the ingress port field has so little influence on packet pro‐
1772 cessing, it does not ordinarily make sense to modify the ingress port
1773 field. The field is writable only to support the occasional use case
1774 where the ingress port’s roles in packet egress, described above,
1775 become troublesome. For example, actions=load:0->NXM_OF_IN_PORT[],out‐
1776 put:123 will output to port 123 regardless of whether it is in the
1777 ingress port. If the ingress port is important, then one may save and
1778 restore it on the stack:
1779 actions=push:NXM_OF_IN_PORT[],load:0->NXM_OF_IN_PORT[],output:123,pop:NXM_OF_IN_PORT[]
1781 or, in Open vSwitch 2.7 or later, use the clone action to save and
1784 restore it:
1785 actions=clone(load:0->NXM_OF_IN_PORT[],output:123)
1787 The ability to modify the ingress port is an Open vSwitch extension to
1790 OpenFlow.
1791 OXM Ingress Port Field
1793 Name: in_port_oxm
1795 Width: 32 bits
1796 Format: OpenFlow 1.1+ port
1797 Masking: not maskable
1798 Prerequisites: none
1799 Access: read/write
1800 OpenFlow 1.0: not supported
1801 OpenFlow 1.1: yes (exact match only)
1802 OXM: OXM_OF_IN_PORT (0) since OpenFlow 1.2 and Open vSwitch
1805 1.7
1806 NXM: none
1807 OpenFlow 1.1 and later use a 32-bit port number, so this field supplies
1809 a 32-bit view of the ingress port. Current versions of Open vSwitch
1810 support only a 16-bit range of ports:
1811 · OpenFlow 1.0 ports 0x0000 to 0xfeff, inclusive, map to
1813 OpenFlow 1.1 port numbers with the same values.
1814 · OpenFlow 1.0 ports 0xff00 to 0xffff, inclusive, map to
1816 OpenFlow 1.1 port numbers 0xffffff00 to 0xffffffff.
1817 · OpenFlow 1.1 ports 0x0000ff00 to 0xfffffeff are not
1819 mapped and not supported.
1820 in_port and in_port_oxm are two views of the same information, so all
1822 of the comments on in_port apply to in_port_oxm too. Modifying in_port
1823 changes in_port_oxm, and vice versa.
1824 Setting in_port_oxm to an unsupported value yields unspecified behav‐
1826 ior.
1827 Output Queue Field
1829 Name: skb_priority
1831 Width: 32 bits
1833 Format: hexadecimal
1834 Masking: not maskable
1835 Prerequisites: none
1836 Access: read-only
1837 OpenFlow 1.0: not supported
1838 OpenFlow 1.1: not supported
1839 OXM: none
1840 NXM: none
1841 Future Directions: Open vSwitch implements the output queue as a field,
1843 but does not currently expose it through OXM or NXM for matching pur‐
1844 poses. If this turns out to be a useful feature, it could be imple‐
1845 mented in future versions. Only the set_queue, enqueue, and pop_queue
1846 actions currently influence the output queue.
1847 This field influences how packets in the flow will be queued, for qual‐
1849 ity of service (QoS) purposes, when they egress the switch. Its range
1850 of meaningful values, and their meanings, varies greatly from one Open‐
1851 Flow implementation to another. Even within a single implementation,
1852 there is no guarantee that all OpenFlow ports have the same queues con‐
1853 figured or that all OpenFlow ports in an implementation can be config‐
1854 ured the same way queue-wise.
1855 Configuring queues on OpenFlow is not well standardized. On Linux, Open
1857 vSwitch supports queue configuration via OVSDB, specifically the QoS
1858 and Queue tables (see ovs-vswitchd.conf.db(5) for details). Ports of
1859 Open vSwitch to other platforms might require queue configuration
1860 through some separate protocol (such as a CLI). Even on Linux, Open
1861 vSwitch exposes only a fraction of the kernel’s queuing features
1862 through OVSDB, so advanced or unusual uses might require use of sepa‐
1863 rate utilities (e.g. tc). OpenFlow switches other than Open vSwitch
1864 might use OF-CONFIG or any of the configuration methods mentioned
1865 above. Finally, some OpenFlow switches have a fixed number of fixed-
1866 function queues (e.g. eight queues with strictly defined priorities)
1867 and others do not support any control over queuing.
1868 The only output queue that all OpenFlow implementations must support is
1870 zero, to identify a default queue, whose properties are implementation-
1871 defined. Outputting a packet to a queue that does not exist on the out‐
1872 put port yields unpredictable behavior: among the possibilities are
1873 that the packet might be dropped or transmitted with a very high or
1874 very low priority.
1875 OpenFlow 1.0 only allowed output queues to be specified as part of an
1877 enqueue action that specified both a queue and an output port. That is,
1878 OpenFlow 1.0 treats the queue as an argument to an action, not as a
1879 field.
1880 To increase flexibility, OpenFlow 1.1 added an action to set the output
1882 queue. This model was carried forward, without change, through OpenFlow
1883 1.5.
1884 Open vSwitch implements the native queuing model of each OpenFlow ver‐
1886 sion it supports. Open vSwitch also includes an extension for setting
1887 the output queue as an action in OpenFlow 1.0.
1888 When a packet ingresses into an OpenFlow switch, the output queue is
1890 ordinarily set to 0, indicating the default queue. However, Open
1891 vSwitch supports various ways to forward a packet from one OpenFlow
1892 switch to another within a single host. In these cases, Open vSwitch
1893 maintains the output queue across the forwarding step. For example:
1894 · A hop across an Open vSwitch ``patch port’’ (which does
1896 not actually involve queuing) preserves the output queue.
1897 · When a flow sets the output queue then outputs to an
1899 OpenFlow tunnel port, the encapsulation preserves the
1900 output queue. If the kernel TCP/IP stack routes the
1901 encapsulated packet directly to a physical interface,
1902 then that output honors the output queue. Alternatively,
1903 if the kernel routes the encapsulated packet to another
1904 Open vSwitch bridge, then the output queue set previously
1905 becomes the initial output queue on ingress to the second
1906 bridge and will thus be used for further output actions
1907 (unless overridden by a new ``set queue’’ action).
1908 (This description reflects the current behavior of Open
1910 vSwitch on Linux. This behavior relies on details of the
1911 Linux TCP/IP stack. It could be difficult to make ports
1912 to other operating systems behave the same way.)
1913 Packet Mark Field
1915 Name: pkt_mark
1917 Width: 32 bits
1918 Format: hexadecimal
1919 Masking: arbitrary bitwise masks
1920 Prerequisites: none
1921 Access: read/write
1922 OpenFlow 1.0: not supported
1923 OpenFlow 1.1: not supported
1924 OXM: none
1925 NXM: NXM_NX_PKT_MARK (33) since Open vSwitch 2.0
1926 Packet mark comes to Open vSwitch from the Linux kernel, in which the
1928 sk_buff data structure that represents a packet contains a 32-bit mem‐
1929 ber named skb_mark. The value of skb_mark propagates along with the
1930 packet it accompanies wherever the packet goes in the kernel. It has no
1931 predefined semantics but various kernel-user interfaces can set and
1932 match on it, which makes it suitable for ``marking’’ packets at one
1933 point in their handling and then acting on the mark later. With ipta‐
1934 bles, for example, one can mark some traffic specially at ingress and
1935 then handle that traffic differently at egress based on the marked
1936 value.
1937 Packet mark is an attempt at a generalization of the skb_mark concept
1939 beyond Linux, at least through more generic naming. Like skb_priority,
1940 packet mark is preserved across forwarding steps within a machine.
1941 Unlike skb_priority, packet mark has no direct effect on packet for‐
1942 warding: the value set in packet mark does not matter unless some later
1943 OpenFlow table or switch matches on packet mark, or unless the packet
1944 passes through some other kernel subsystem that has been configured to
1945 interpret packet mark in specific ways, e.g. through iptables configu‐
1946 ration mentioned above.
1947 Preserving packet mark across kernel forwarding steps relies heavily on
1949 kernel support, which ports to non-Linux operating systems may not
1950 have. Regardless of operating system support, Open vSwitch supports
1951 packet mark within a single bridge and across patch ports.
1952 The value of packet mark when a packet ingresses into the first Open
1954 vSwich bridge is typically zero, but it could be nonzero if its value
1955 was previously set by some kernel subsystem.
1956 Action Set Output Port Field
1958 Name: actset_output
1960 Width: 32 bits
1961 Format: OpenFlow 1.1+ port
1962 Masking: not maskable
1963 Prerequisites: none
1964 Access: read-only
1965 OpenFlow 1.0: not supported
1966 OpenFlow 1.1: not supported
1967 OXM: ONFOXM_ET_ACTSET_OUTPUT (43) since OpenFlow 1.3 and
1968 Open vSwitch 2.4; OXM_OF_ACTSET_OUTPUT [22m(43) since
1969 OpenFlow 1.5 and Open vSwitch 2.4
1970 NXM: none
1971 Holds the output port currently in the OpenFlow action set (i.e. from
1973 an output action within a write_actions instruction). Its value is an
1974 OpenFlow port number. If there is no output port in the OpenFlow action
1975 set, or if the output port will be ignored (e.g. because there is an
1976 output group in the OpenFlow action set), then the value will be
1977 OFPP_UNSET.
1978 Open vSwitch allows any table to match this field. OpenFlow, however,
1980 only requires this field to be matchable from within an OpenFlow egress
1981 table (a feature that Open vSwitch does not yet implement).
1982 Packet Type Field
1984 Name: packet_type
1987 Width: 32 bits
1988 Format: packet type
1989 Masking: not maskable
1990 Prerequisites: none
1991 Access: read-only
1992 OpenFlow 1.0: not supported
1993 OpenFlow 1.1: not supported
1994 OXM: OXM_OF_PACKET_TYPE [22m(44) since OpenFlow 1.5 and Open
1995 vSwitch 2.8
1996 NXM: none
1997 The type of the packet in the format specified in OpenFlow 1.5:
1999 Packet type
2001 <--------->
2002 16 16
2003 +---+-------+
2004 |ns |ns_type| ...
2005 +---+-------+
2006 The upper 16 bits, ns, are a namespace. The meaning of ns_type depends
2009 on the namespace. The packet type field is specified and displayed in
2010 the format (ns,ns_type).
2011 Open vSwitch currently supports the following classes of packet types
2013 for matching:
2014 (0,0) Ethernet.
2016 (1,ethertype)
2018 The specified ethertype. Open vSwitch can forward packets
2019 with any ethertype, but it can only match on and process
2020 data fields for the following supported packet types:
2021 (1,0x800)
2023 IPv4
2024 (1,0x806)
2026 ARP
2027 (1,0x86dd)
2029 IPv6
2030 (1,0x8847)
2032 MPLS
2033 (1,0x8848)
2035 MPLS multicast
2036 (1,0x8035)
2038 RARP
2039 (1,0x894f)
2041 NSH
2042 Consider the distinction between a packet with packet_type=(0,0),
2044 dl_type=0x800 and one with packet_type=(1,0x800). The former is an Eth‐
2045 ernet frame that contains an IPv4 packet, like this:
2046 Ethernet IPv4
2048 <-----------> <--------------->
2049 48 48 16 8 32 32
2050 +---+---+-----+ +---+-----+---+---+
2051 |dst|src|type | |...|proto|src|dst| ...
2052 +---+---+-----+ +---+-----+---+---+
2053 0x800
2054 The latter is an IPv4 packet not encapsulated inside any outer frame,
2057 like this:
2058 IPv4
2060 <--------------->
2061 8 32 32
2062 +---+-----+---+---+
2063 |...|proto|src|dst| ...
2064 +---+-----+---+---+
2065 Matching on packet_type is a pre-requisite for matching on any data
2068 field, but for backward compatibility, when a match on a data field is
2069 present without a packet_type match, Open vSwitch acts as though a
2070 match on (0,0) (Ethernet) had been supplied. Similarly, when Open
2071 vSwitch sends flow match information to a controller, e.g. in a reply
2072 to a request to dump the flow table, Open vSwitch omits a match on
2073 packet type (0,0) if it would be implied by a data field match.
2074
2076 Summary:
2077 Name Bytes Mask RW? Prereqs NXM/OXM Support
2078 ──────────── ────── ───── ──── ──────── ────────────────
2080 ct_state 4 yes no none OVS 2.5+
2081 ct_zone 2 no no none OVS 2.5+
2082 ct_mark 4 yes yes none OVS 2.5+
2084 ct_label 16 yes yes none OVS 2.5+
2085 ct_nw_src 4 yes no CT OVS 2.8+
2086 ct_nw_dst 4 yes no CT OVS 2.8+
2088 ct_ipv6_src 16 yes no CT OVS 2.8+
2089 ct_ipv6_dst 16 yes no CT OVS 2.8+
2090 ct_nw_proto 1 no no CT OVS 2.8+
2092 ct_tp_src 2 yes no CT OVS 2.8+
2093 ct_tp_dst 2 yes no CT OVS 2.8+
2094 Open vSwitch 2.5 and later support ``connection tracking,’’ which
2096 allows bidirectional streams of packets to be statefully grouped into
2097 connections. Open vSwitch connection tracking, for example, identifies
2098 the patterns of TCP packets that indicates a successfully initiated
2099 connection, as well as those that indicate that a connection has been
2100 torn down. Open vSwitch connection tracking can also identify related
2101 connections, such as FTP data connections spawned from FTP control con‐
2102 nections.
2103 An individual packet passing through the pipeline may be in one of two
2105 states, ``untracked’’ or ``tracked,’’ which may be distinguished via
2106 the ``trk’’ flag in ct_state. A packet is untracked at the beginning of
2107 the Open vSwitch pipeline and continues to be untracked until the pipe‐
2108 line invokes the ct action. The connection tracking fields are all
2109 zeroes in an untracked packet. When a flow in the Open vSwitch pipeline
2110 invokes the ct action, the action initializes the connection tracking
2111 fields and the packet becomes tracked for the remainder of its process‐
2112 ing.
2113 The connection tracker stores connection state in an internal table,
2115 but it only adds a new entry to this table when a ct action for a new
2116 connection invokes ct with the commit parameter. For a given connec‐
2117 tion, when a pipeline has executed ct, but not yet with commit, the
2118 connection is said to be uncommitted. State for an uncommitted connec‐
2119 tion is ephemeral and does not persist past the end of the pipeline, so
2120 some features are only available to committed connections. A connection
2121 would typically be left uncommitted as a way to drop its packets.
2122 Connection tracking is an Open vSwitch extension to OpenFlow.
2124 Connection Tracking State Field
2126 Name: ct_state
2128 Width: 32 bits
2129 Format: ct state
2130 Masking: arbitrary bitwise masks
2132 Prerequisites: none
2133 Access: read-only
2134 OpenFlow 1.0: not supported
2136 OpenFlow 1.1: not supported
2137 OXM: none
2138 NXM: NXM_NX_CT_STATE (105) since Open vSwitch 2.5
2140 This field holds several flags that can be used to determine the state
2142 of the connection to which the packet belongs.
2143 Matches on this field are most conveniently written in terms of sym‐
2145 bolic names (listed below), each preceded by either + for a flag that
2146 must be set, or - for a flag that must be unset, without any other
2147 delimiters between the flags. Flags not mentioned are wildcarded. For
2148 example, tcp,ct_state=+trk-new matches TCP packets that have been run
2149 through the connection tracker and do not establish a new connection.
2150 Matches can also be written as flags/mask, where flags and mask are
2151 32-bit numbers in decimal or in hexadecimal prefixed by 0x.
2152 The following flags are defined:
2154 new (0x01)
2156 A new connection. Set to 1 if this is an uncommitted con‐
2157 nection.
2158 est (0x02)
2160 Part of an existing connection. Set to 1 if this is a
2161 committed connection.
2162 rel (0x04)
2164 Related to an existing connection, e.g. an ICMP ``desti‐
2165 nation unreachable’’ message or an FTP data connections.
2166 This flag will only be 1 if the connection to which this
2167 one is related is committed.
2168 Connections identified as rel are separate from the orig‐
2170 inating connection and must be committed separately. All
2171 packets for a related connection will have the rel flag
2172 set, not just the initial packet.
2173 rpl (0x08)
2175 This packet is in the reply direction, meaning that it is
2176 in the opposite direction from the packet that initiated
2177 the connection. This flag will only be 1 if the connec‐
2178 tion is committed.
2179 inv (0x10)
2181 The state is invalid, meaning that the connection tracker
2182 couldn’t identify the connection. This flag is a catch-
2183 all for problems in the connection or the connection
2184 tracker, such as:
2185 · L3/L4 protocol handler is not loaded/unavailable.
2187 With the Linux kernel datapath, this may mean that
2188 the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules
2189 are not loaded.
2190 · L3/L4 protocol handler determines that the packet
2192 is malformed.
2193 · Packets are unexpected length for protocol.
2195 trk (0x20)
2197 This packet is tracked, meaning that it has previously
2198 traversed the connection tracker. If this flag is not
2199 set, then no other flags will be set. If this flag is
2200 set, then the packet is tracked and other flags may also
2201 be set.
2202 snat (0x40)
2204 This packet was transformed by source address/port trans‐
2205 lation by a preceding ct action. Open vSwitch 2.6 added
2206 this flag.
2207 dnat (0x80)
2209 This packet was transformed by destination address/port
2210 translation by a preceding ct action. Open vSwitch 2.6
2211 added this flag.
2212 There are additional constraints on these flags, listed in decreasing
2214 order of precedence below:
2215 1.
2217 If trk is unset, no other flags are set.
2218 2.
2220 If trk is set, one or more other flags may be set.
2221 3.
2223 If inv is set, only the trk flag is also set.
2224 4.
2226 new and est are mutually exclusive.
2227 5.
2229 new and rpl are mutually exclusive.
2230 6.
2232 rel may be set in conjunction with any other flags.
2233 Future versions of Open vSwitch may define new flags.
2235 Connection Tracking Zone Field
2237 Name: ct_zone
2239 Width: 16 bits
2240 Format: hexadecimal
2241 Masking: not maskable
2242 Prerequisites: none
2243 Access: read-only
2244 OpenFlow 1.0: not supported
2245 OpenFlow 1.1: not supported
2247 OXM: none
2248 NXM: NXM_NX_CT_ZONE (106) since Open vSwitch 2.5
2249 A connection tracking zone, the zone value passed to the most recent ct
2251 action. Each zone is an independent connection tracking context, so
2252 tracking the same packet in multiple contexts requires using the ct
2253 action multiple times.
2254 Connection Tracking Mark Field
2256 Name: ct_mark
2258 Width: 32 bits
2259 Format: hexadecimal
2260 Masking: arbitrary bitwise masks
2261 Prerequisites: none
2262 Access: read/write
2263 OpenFlow 1.0: not supported
2265 OpenFlow 1.1: not supported
2266 OXM: none
2267 NXM: NXM_NX_CT_MARK (107) since Open vSwitch 2.5
2268 The metadata committed, by an action within the exec parameter to the
2270 ct action, to the connection to which the current packet belongs.
2271 Connection Tracking Label Field
2273 Name: ct_label
2275 Width: 128 bits
2276 Format: hexadecimal
2277 Masking: arbitrary bitwise masks
2278 Prerequisites: none
2279 Access: read/write
2280 OpenFlow 1.0: not supported
2281 OpenFlow 1.1: not supported
2283 OXM: none
2284 NXM: NXM_NX_CT_LABEL (108) since Open vSwitch 2.5
2285 The label committed, by an action within the exec parameter to the ct
2287 action, to the connection to which the current packet belongs.
2288 Open vSwitch 2.8 introduced the matching support for connection tracker
2290 original direction 5-tuple fields.
2291 For non-committed non-related connections the conntrack original direc‐
2293 tion tuple fields always have the same values as the corresponding
2294 headers in the packet itself. For any other packets of a committed con‐
2295 nection the conntrack original direction tuple fields reflect the val‐
2296 ues from that initial non-committed non-related packet, and thus may be
2297 different from the actual packet headers, as the actual packet headers
2298 may be in reverse direction (for reply packets), transformed by NAT
2299 (when nat option was applied to the connection), or be of different
2300 protocol (i.e., when an ICMP response is sent to an UDP packet). In
2301 case of related connections, e.g., an FTP data connection, the original
2302 direction tuple contains the original direction headers from the master
2303 connection, e.g., an FTP control connection.
2304 The following fields are populated by the ct action, and require a
2306 match to a valid connection tracking state as a prerequisite, in addi‐
2307 tion to the IP or IPv6 ethertype match. Examples of valid connection
2308 tracking state matches include ct_state=+new, ct_state=+est,
2309 ct_state=+rel, and ct_state=+trk-inv.
2310 Connection Tracking Original Direction IPv4 Source Address Field
2312 Name: ct_nw_src
2314 Width: 32 bits
2315 Format: IPv4
2316 Masking: arbitrary bitwise masks
2317 Prerequisites: CT
2319 Access: read-only
2320 OpenFlow 1.0: not supported
2321 OpenFlow 1.1: not supported
2322 OXM: none
2323 NXM: NXM_NX_CT_NW_SRC (120) since Open vSwitch 2.8
2324 Matches IPv4 conntrack original direction tuple source address. See the
2326 paragraphs above for general description to the conntrack original
2327 direction tuple. Introduced in Open vSwitch 2.8.
2328 Connection Tracking Original Direction IPv4 Destination Address Field
2330 Name: ct_nw_dst
2332 Width: 32 bits
2333 Format: IPv4
2334 Masking: arbitrary bitwise masks
2335 Prerequisites: CT
2337 Access: read-only
2338 OpenFlow 1.0: not supported
2339 OpenFlow 1.1: not supported
2340 OXM: none
2341 NXM: NXM_NX_CT_NW_DST (121) since Open vSwitch 2.8
2342 Matches IPv4 conntrack original direction tuple destination address.
2344 See the paragraphs above for general description to the conntrack orig‐
2345 inal direction tuple. Introduced in Open vSwitch 2.8.
2346 Connection Tracking Original Direction IPv6 Source Address Field
2348 Name: ct_ipv6_src
2350 Width: 128 bits
2351 Format: IPv6
2352 Masking: arbitrary bitwise masks
2353 Prerequisites: CT
2355 Access: read-only
2356 OpenFlow 1.0: not supported
2357 OpenFlow 1.1: not supported
2358 OXM: none
2359 NXM: NXM_NX_CT_IPV6_SRC (122) since Open vSwitch 2.8
2360 Matches IPv6 conntrack original direction tuple source address. See the
2362 paragraphs above for general description to the conntrack original
2363 direction tuple. Introduced in Open vSwitch 2.8.
2364 Connection Tracking Original Direction IPv6 Destination Address Field
2366 Name: ct_ipv6_dst
2368 Width: 128 bits
2369 Format: IPv6
2370 Masking: arbitrary bitwise masks
2371 Prerequisites: CT
2373 Access: read-only
2374 OpenFlow 1.0: not supported
2375 OpenFlow 1.1: not supported
2376 OXM: none
2377 NXM: NXM_NX_CT_IPV6_DST (123) since Open vSwitch 2.8
2378 Matches IPv6 conntrack original direction tuple destination address.
2380 See the paragraphs above for general description to the conntrack orig‐
2381 inal direction tuple. Introduced in Open vSwitch 2.8.
2382 Connection Tracking Original Direction IP Protocol Field
2384 Name: ct_nw_proto
2386 Width: 8 bits
2387 Format: decimal
2388 Masking: not maskable
2389 Prerequisites: CT
2391 Access: read-only
2392 OpenFlow 1.0: not supported
2393 OpenFlow 1.1: not supported
2394 OXM: none
2395 NXM: NXM_NX_CT_NW_PROTO (119) since Open vSwitch 2.8
2396 Matches conntrack original direction tuple IP protocol type, which is
2398 specified as a decimal number between 0 and 255, inclusive (e.g. 1 to
2399 match ICMP packets or 6 to match TCP packets). In case of, for example,
2400 an ICMP response to an UDP packet, this may be different from the IP
2401 protocol type of the packet itself. See the paragraphs above for gen‐
2402 eral description to the conntrack original direction tuple. Introduced
2403 in Open vSwitch 2.8.
2404 Connection Tracking Original Direction Transport Layer Source Port
2406 Field
2407 Name: ct_tp_src
2409 Width: 16 bits
2410 Format: decimal
2411 Masking: arbitrary bitwise masks
2412 Prerequisites: CT
2413 Access: read-only
2414 OpenFlow 1.0: not supported
2415 OpenFlow 1.1: not supported
2416 OXM: none
2418 NXM: NXM_NX_CT_TP_SRC (124) since Open vSwitch 2.8
2419 Bitwise match on the conntrack original direction tuple transport
2421 source, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or 132
2422 for SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58 for ICMPv6,
2423 the lower 8 bits of MFF_CT_TP_SRC matches the conntrack original direc‐
2424 tion ICMP type. See the paragraphs above for general description to the
2425 conntrack original direction tuple. Introduced in Open vSwitch 2.8.
2426 Connection Tracking Original Direction Transport Layer Source Port
2428 Field
2429 Name: ct_tp_dst
2431 Width: 16 bits
2432 Format: decimal
2433 Masking: arbitrary bitwise masks
2434 Prerequisites: CT
2436 Access: read-only
2437 OpenFlow 1.0: not supported
2438 OpenFlow 1.1: not supported
2439 OXM: none
2440 NXM: NXM_NX_CT_TP_DST (125) since Open vSwitch 2.8
2441 Bitwise match on the conntrack original direction tuple transport des‐
2443 tination port, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or
2444 132 for SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58 for
2445 ICMPv6, the lower 8 bits of MFF_CT_TP_DST matches the conntrack origi‐
2446 nal direction ICMP code. See the paragraphs above for general descrip‐
2447 tion to the conntrack original direction tuple. Introduced in Open
2448 vSwitch 2.8.
2449
2451 Summary:
2452 Name Bytes Mask RW? Prereqs NXM/OXM Support
2453 ───────── ────── ───── ──── ──────── ─────────────────────
2455 metadata 8 yes yes none OF 1.2+ and OVS 1.8+
2456 reg0 4 yes yes none OVS 1.1+
2457 reg1 4 yes yes none OVS 1.1+
2458 reg2 4 yes yes none OVS 1.1+
2460 reg3 4 yes yes none OVS 1.1+
2461 reg4 4 yes yes none OVS 1.3+
2462 reg5 4 yes yes none OVS 1.7+
2463 reg6 4 yes yes none OVS 1.7+
2465 reg7 4 yes yes none OVS 1.7+
2466 reg8 4 yes yes none OVS 2.6+
2467 reg9 4 yes yes none OVS 2.6+
2468 reg10 4 yes yes none OVS 2.6+
2470 reg11 4 yes yes none OVS 2.6+
2471 reg12 4 yes yes none OVS 2.6+
2472 reg13 4 yes yes none OVS 2.6+
2473 reg14 4 yes yes none OVS 2.6+
2475 reg15 4 yes yes none OVS 2.6+
2476 xreg0 8 yes yes none OF 1.3+ and OVS 2.4+
2477 xreg1 8 yes yes none OF 1.3+ and OVS 2.4+
2478 xreg2 8 yes yes none OF 1.3+ and OVS 2.4+
2480 xreg3 8 yes yes none OF 1.3+ and OVS 2.4+
2481 xreg4 8 yes yes none OF 1.3+ and OVS 2.4+
2482 xreg5 8 yes yes none OF 1.3+ and OVS 2.4+
2483 xreg6 8 yes yes none OF 1.3+ and OVS 2.4+
2485 xreg7 8 yes yes none OF 1.3+ and OVS 2.4+
2486 xxreg0 16 yes yes none OVS 2.6+
2487 xxreg1 16 yes yes none OVS 2.6+
2488 xxreg2 16 yes yes none OVS 2.6+
2490 xxreg3 16 yes yes none OVS 2.6+
2491 These fields give an OpenFlow switch space for temporary storage while
2493 the pipeline is running. Whereas metadata fields can have a meaningful
2494 initial value and can persist across some hops across OpenFlow
2495 switches, registers are always initially 0 and their values never per‐
2496 sist across inter-switch hops (not even across patch ports).
2497 OpenFlow Metadata Field
2499 Name: metadata
2501 Width: 64 bits
2502 Format: hexadecimal
2503 Masking: arbitrary bitwise masks
2505 Prerequisites: none
2506 Access: read/write
2507 OpenFlow 1.0: not supported
2508 OpenFlow 1.1: yes
2510 OXM: OXM_OF_METADATA [22m(2) since OpenFlow 1.2 and Open
2511 vSwitch 1.8
2512 NXM: none
2513 This field is the oldest standardized OpenFlow register field, intro‐
2515 duced in OpenFlow 1.1. It was introduced to model the limited number of
2516 user-defined bits that some ASIC-based switches can carry through their
2517 pipelines. Because of hardware limitations, OpenFlow allows switches to
2518 support writing and masking only an implementation-defined subset of
2519 bits, even no bits at all. The Open vSwitch software switch always sup‐
2520 ports all 64 bits, but of course an Open vSwitch port to an ASIC would
2521 have the same restriction as the ASIC itself.
2522 This field has an OXM code point, but OpenFlow 1.4 and earlier allow it
2524 to be modified only with a specialized instruction, not with a ``set-
2525 field’’ action. OpenFlow 1.5 removes this restriction. Open vSwitch
2526 does not enforce this restriction, regardless of OpenFlow version.
2527 Register 0 Field
2529 Name: reg0
2531 Width: 32 bits
2532 Format: hexadecimal
2533 Masking: arbitrary bitwise masks
2535 Prerequisites: none
2536 Access: read/write
2537 OpenFlow 1.0: not supported
2538 OpenFlow 1.1: not supported
2540 OXM: none
2541 NXM: NXM_NX_REG0 (0) since Open vSwitch 1.1
2542 This is the first of several Open vSwitch registers, all of which have
2544 the same properties. Open vSwitch 1.1 introduced registers 0, 1, 2, and
2545 3, version 1.3 added register 4, version 1.7 added registers 5, 6, and
2546 7, and version 2.6 added registers 8 through 15.
2547 Extended Register 0 Field
2549 Name: xreg0
2551 Width: 64 bits
2552 Format: hexadecimal
2553 Masking: arbitrary bitwise masks
2555 Prerequisites: none
2556 Access: read/write
2557 OpenFlow 1.0: not supported
2558 OpenFlow 1.1: not supported
2560 OXM: OXM_OF_PKT_REG0 [22m(0) since OpenFlow 1.3 and Open
2561 vSwitch 2.4
2562 NXM: none
2563 This is the first of the registers introduced in OpenFlow 1.5. OpenFlow
2565 1.5 calls these fields just the ``packet registers,’’ but Open vSwitch
2566 already had 32-bit registers by that name, so Open vSwitch uses the
2567 name ``extended registers’’ in an attempt to reduce confusion. The
2568 standard allows for up to 128 registers, each 64 bits wide, but Open
2569 vSwitch only implements 4 (in versions 2.4 and 2.5) or 8 (in version
2570 2.6 and later).
2571 Each of the 64-bit extended registers overlays two of the 32-bit regis‐
2573 ters: xreg0 overlays reg0 and reg1, with reg0 supplying the most-sig‐
2574 nificant bits of xreg0 and reg1 the least-significant. Similarly, xreg1
2575 overlays reg2 and reg3, and so on.
2576 The OpenFlow specification says, ``In most cases, the packet registers
2578 can not be matched in tables, i.e. they usually can not be used in the
2579 flow entry match structure’’ [OpenFlow 1.5, section 7.2.3.10], but
2580 there is no reason for a software switch to impose such a restriction,
2581 and Open vSwitch does not.
2582 Double-Extended Register 0 Field
2584 Name: xxreg0
2586 Width: 128 bits
2587 Format: hexadecimal
2588 Masking: arbitrary bitwise masks
2590 Prerequisites: none
2591 Access: read/write
2592 OpenFlow 1.0: not supported
2593 OpenFlow 1.1: not supported
2595 OXM: none
2596 NXM: NXM_NX_XXREG0 (111) since Open vSwitch 2.6
2597 This is the first of the double-extended registers introduce in Open
2599 vSwitch 2.6. Each of the 128-bit extended registers overlays four of
2600 the 32-bit registers: xxreg0 overlays reg0 through reg3, with reg0 sup‐
2601 plying the most-significant bits of xxreg0 and reg3 the least-signifi‐
2602 cant. xxreg1 similarly overlays reg4 through reg7, and so on.
2603
2605 Summary:
2606 Name Bytes Mask RW? Prereqs NXM/OXM Support
2607 ───────────────────── ────── ───── ──── ───────── ─────────────────────
2609 eth_src aka dl_src 6 yes yes Ethernet OF 1.2+ and OVS 1.1+
2610 eth_dst aka dl_dst 6 yes yes Ethernet OF 1.2+ and OVS 1.1+
2611 eth_type aka dl_type 2 no no Ethernet OF 1.2+ and OVS 1.1+
2612 Ethernet is the only layer-2 protocol that Open vSwitch supports. As
2614 with most software, Open vSwitch and OpenFlow regard an Ethernet frame
2615 to begin with the 14-byte header and end with the final byte of the
2616 payload; that is, the frame check sequence is not considered part of
2617 the frame.
2618 Ethernet Source Field
2620 Name: eth_src (aka dl_src)
2622 Width: 48 bits
2624 Format: Ethernet
2625 Masking: arbitrary bitwise masks
2626 Prerequisites: Ethernet
2627 Access: read/write
2629 OpenFlow 1.0: yes (exact match only)
2630 OpenFlow 1.1: yes
2631 OXM: OXM_OF_ETH_SRC (4) since OpenFlow 1.2 and Open vSwitch
2634 1.7
2635 NXM: NXM_OF_ETH_SRC (2) since Open vSwitch 1.1
2636 The Ethernet source address:
2638 Ethernet
2640 <---------->
2641 48 48 16
2642 +---+---+----+
2643 |dst|src|type| ...
2644 +---+---+----+
2645 Ethernet Destination Field
2648 Name: eth_dst (aka dl_dst)
2650 Width: 48 bits
2651 Format: Ethernet
2652 Masking: arbitrary bitwise masks
2654 Prerequisites: Ethernet
2655 Access: read/write
2656 OpenFlow 1.0: yes (exact match only)
2657 OpenFlow 1.1: yes
2659 OXM: OXM_OF_ETH_DST (3) since OpenFlow 1.2 and Open vSwitch
2660 1.7
2661 NXM: NXM_OF_ETH_DST (1) since Open vSwitch 1.1
2662 The Ethernet destination address:
2664 Ethernet
2666 <---------->
2667 48 48 16
2668 +---+---+----+
2669 |dst|src|type| ...
2670 +---+---+----+
2671 Open vSwitch 1.8 and later support arbitrary masks for source and/or
2674 destination. Earlier versions only support masking the destination with
2675 the following masks:
2676 01:00:00:00:00:00
2678 Match only the multicast bit. Thus,
2679 dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 matches all
2680 multicast (including broadcast) Ethernet packets, and
2681 dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 matches all
2682 unicast Ethernet packets.
2683 fe:ff:ff:ff:ff:ff
2685 Match all bits except the multicast bit. This is probably
2686 not useful.
2687 ff:ff:ff:ff:ff:ff
2689 Exact match (equivalent to omitting the mask).
2690 00:00:00:00:00:00
2692 Wildcard all bits (equivalent to dl_dst=*).
2693 Ethernet Type Field
2695 Name: eth_type (aka dl_type)
2697 Width: 16 bits
2698 Format: hexadecimal
2699 Masking: not maskable
2700 Prerequisites: Ethernet
2702 Access: read-only
2703 OpenFlow 1.0: yes (exact match only)
2704 OpenFlow 1.1: yes (exact match only)
2705 OXM: OXM_OF_ETH_TYPE [22m(5) since OpenFlow 1.2 and Open
2706 vSwitch 1.7
2707 NXM: NXM_OF_ETH_TYPE (3) since Open vSwitch 1.1
2709 The most commonly seen Ethernet frames today use a format called ``Eth‐
2711 ernet II,’’ in which the last two bytes of the Ethernet header specify
2712 the Ethertype. For such a frame, this field is copied from those bytes
2713 of the header, like so:
2714 Ethernet
2716 <---------------->
2717 48 48 16
2718 +---+---+----------+
2719 |dst|src| type | ...
2720 +---+---+----------+
2721 ≥0x600
2722 Every Ethernet type has a value 0x600 (1,536) or greater. When the last
2725 two bytes of the Ethernet header have a value too small to be an Ether‐
2726 net type, then the value found there is the total length of the frame
2727 in bytes, excluding the Ethernet header. An 802.2 LLC header typically
2728 follows the Ethernet header. OpenFlow and Open vSwitch only support LLC
2729 headers with DSAP and SSAP 0xaa and control byte 0x03, which indicate
2730 that a SNAP header follows the LLC header. In turn, OpenFlow and Open
2731 vSwitch only support a SNAP header with organization 0x000000. In such
2732 a case, this field is copied from the type field in the SNAP header,
2733 like this:
2734 Ethernet LLC SNAP
2736 <------------> <------------> <----------------->
2737 48 48 16 8 8 8 24 16
2738 +---+---+------+ +----+----+----+ +--------+----------+
2739 |dst|src| type | |DSAP|SSAP|cntl| | org | type | ...
2740 +---+---+------+ +----+----+----+ +--------+----------+
2741 <0x600 0xaa 0xaa 0x03 0x000000 ≥0x600
2742 When an 802.1Q header is inserted after the Ethernet source and desti‐
2745 nation, this field is populated with the encapsulated Ethertype, not
2746 the 802.1Q Ethertype. With an Ethernet II inner frame, the result looks
2747 like this:
2748 Ethernet 802.1Q Ethertype
2750 <------> <--------> <-------->
2751 48 48 16 16 16
2752 +----+---+ +------+---+ +----------+
2753 |dst |src| | TPID |TCI| | type | ...
2754 +----+---+ +------+---+ +----------+
2755 0x8100 ≥0x600
2756 LLC and SNAP encapsulation look like this with an 802.1Q header:
2759 Ethernet 802.1Q Ethertype LLC SNAP
2761 <------> <--------> <-------> <------------> <----------------->
2762 48 48 16 16 16 8 8 8 24 16
2763 +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2764 |dst |src| | TPID |TCI| | type | |DSAP|SSAP|cntl| | org | type | ...
2765 +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2766 0x8100 <0x600 0xaa 0xaa 0x03 0x000000 ≥0x600
2767 When a packet doesn’t match any of the header formats described above,
2770 Open vSwitch and OpenFlow set this field to 0x5ff
2771 (OFP_DL_TYPE_NOT_ETH_TYPE).
2772
2774 Summary:
2775 Name Bytes Mask RW? Prereqs NXM/OXM Support
2776 ──────────── ──────────────── ───── ──── ───────── ─────────────────────
2778 dl_vlan 2 (low 12 bits) no yes Ethernet
2779 dl_vlan_pcp 1 (low 3 bits) no yes Ethernet
2780 vlan_vid 2 (low 12 bits) yes yes Ethernet OF 1.2+ and OVS 1.7+
2782 vlan_pcp 1 (low 3 bits) no yes VLAN VID OF 1.2+ and OVS 1.7+
2783 vlan_tci 2 yes yes Ethernet OVS 1.1+
2784 The 802.1Q VLAN header causes more trouble than any other 4 bytes in
2786 networking. OpenFlow 1.0, 1.1, and 1.2+ all treat VLANs differently.
2787 Open vSwitch extensions add another variant to the mix. Open vSwitch
2788 reconciles all four treatments as best it can.
2789 VLAN Header Format
2791 An 802.1Q VLAN header consists of two 16-bit fields:
2792 TPID TCI
2794 <-------> <--------->
2795 16 3 1 12
2796 +---------+---+---+---+
2797 |Ethertype|PCP|CFI|VID|
2798 +---------+---+---+---+
2799 0x8100 0
2800 The first 16 bits of the VLAN header, the TPID (Tag Protocol IDenti‐
2803 fier), is an Ethertype. When the VLAN header is inserted just after the
2804 source and destination MAC addresses in a Ethertype frame, the TPID
2805 serves to identify the presence of the VLAN. The standard TPID, the
2806 only one that Open vSwitch supports, is 0x8100. OpenFlow 1.0 explicitly
2807 supports only TPID 0x8100. OpenFlow 1.1, but not earlier or later ver‐
2808 sions, also requires support for TPID 0x88a8 (Open vSwitch does not
2809 support this). OpenFlow 1.2 through 1.5 do not require support for spe‐
2810 cific TPIDs (the ``push vlan header’’ action does say that only 0x8100
2811 and 0x88a8 should be pushed). No version of OpenFlow provides a way to
2812 distinguish or match on the TPID.
2813 The remaining 16 bits of the VLAN header, the TCI (Tag Control Informa‐
2815 tion), is subdivided into three subfields:
2816 · PCP (Priority Control Point), is a 3-bit 802.1p priority.
2818 The lowest priority is value 1, the second-lowest is
2819 value 0, and priority increases from 2 up to highest pri‐
2820 ority 7.
2821 · CFI (Canonical Format Indicator), is a 1-bit field. On an
2823 Ethernet network, its value is always 0. This led to it
2824 later being repurposed under the name DEI (Drop Eligibil‐
2825 ity Indicator). By either name, OpenFlow and Open vSwitch
2826 don’t provide any way to match or set this bit.
2827 · VID (VLAN IDentifier), is a 12-bit VLAN. If the VID is 0,
2829 then the frame is not part of a VLAN. In that case, the
2830 VLAN header is called a priority tag because it is only
2831 meaningful for assigning the frame a priority. VID 0xfff
2832 (4,095) is reserved.
2833 See eth_type for illustrations of a complete Ethernet frame with 802.1Q
2835 tag included.
2836 Multiple VLANs
2838 Open vSwitch can match only a single VLAN header. If more than one VLAN
2839 header is present, then eth_type holds the TPID of the inner VLAN
2840 header. Open vSwitch stops parsing the packet after the inner TPID, so
2841 matching further into the packet (e.g. on the inner TCI or L3 fields)
2842 is not possible.
2843 OpenFlow only directly supports matching a single VLAN header. In Open‐
2845 Flow 1.1 or later, one OpenFlow table can match on the outermost VLAN
2846 header and pop it off, and a later OpenFlow table can match on the next
2847 outermost header. Open vSwitch does not support this.
2848 VLAN Field Details
2850 The four variants have three different levels of expressiveness: Open‐
2851 Flow 1.0 and 1.1 VLAN matching are less powerful than OpenFlow 1.2+
2852 VLAN matching, which is less powerful than Open vSwitch extension VLAN
2853 matching.
2854 OpenFlow 1.0 VLAN Fields
2856 OpenFlow 1.0 uses two fields, called dl_vlan and dl_vlan_pcp, each of
2857 which can be either exact-matched or wildcarded, to specify VLAN
2858 matches:
2859 · When both dl_vlan and dl_vlan_pcp are wildcarded, the
2861 flow matches packets without an 802.1Q header or with any
2862 802.1Q header.
2863 · The match dl_vlan=0xffff causes a flow to match only
2865 packets without an 802.1Q header. Such a flow should also
2866 wildcard dl_vlan_pcp, since a packet without an 802.1Q
2867 header does not have a PCP. OpenFlow does not specify
2868 what to do if a match on PCP is actually present, but
2869 Open vSwitch ignores it.
2870 · Otherwise, the flow matches only packets with an 802.1Q
2872 header. If dl_vlan is not wildcarded, then the flow only
2873 matches packets with the VLAN ID specified in dl_vlan’s
2874 low 12 bits. If dl_vlan_pcp is not wildcarded, then the
2875 flow only matches packets with the priority specified in
2876 dl_vlan_pcp’s low 3 bits.
2877 OpenFlow does not specify how to interpret the high 4
2879 bits of dl_vlan or the high 5 bits of dl_vlan_pcp. Open
2880 vSwitch ignores them.
2881 OpenFlow 1.1 VLAN Fields
2883 VLAN matching in OpenFlow 1.1 is similar to OpenFlow 1.0. The one
2884 refinement is that when dl_vlan matches on 0xfffe (OFVPID_ANY), the
2885 flow matches only packets with an 802.1Q header, with any VLAN ID. If
2886 dl_vlan_pcp is wildcarded, the flow matches any packet with an 802.1Q
2887 header, regardless of VLAN ID or priority. If dl_vlan_pcp is not wild‐
2888 carded, then the flow only matches packets with the priority specified
2889 in dl_vlan_pcp’s low 3 bits.
2890 OpenFlow 1.1 uses the name OFPVID_NONE, instead of OFP_VLAN_NONE, for a
2892 dl_vlan of 0xffff, but it has the same meaning.
2893 In OpenFlow 1.1, Open vSwitch reports error OFPBMC_BAD_VALUE for an
2895 attempt to match on dl_vlan between 4,096 and 0xfffd, inclusive, or
2896 dl_vlan_pcp greater than 7.
2897 OpenFlow 1.2 VLAN Fields
2899 OpenFlow 1.2+ VLAN ID Field
2900 Name: vlan_vid
2902 Width: 16 bits (only the least-significant 12 bits may be nonzero)
2903 Format: decimal
2904 Masking: arbitrary bitwise masks
2905 Prerequisites: Ethernet
2906 Access: read/write
2907 OpenFlow 1.0: yes (exact match only)
2909 OpenFlow 1.1: yes (exact match only)
2910 OXM: OXM_OF_VLAN_VID (6) since OpenFlow 1.2 and Open vSwitch 1.7
2911 NXM: none
2912 The OpenFlow standard describes this field as consisting of ``12+1’’
2914 bits. On ingress, its value is 0 if no 802.1Q header is present, and
2915 otherwise it holds the VLAN VID in its least significant 12 bits, with
2916 bit 12 (0x1000 aka OFPVID_PRESENT) also set to 1. The three most sig‐
2917 nificant bits are always zero:
2918 OXM_OF_VLAN_VID
2920 <------------->
2921 3 1 12
2922 +---+--+--------+
2923 | |P |VLAN ID |
2924 +---+--+--------+
2925 0
2926 As a consequence of this field’s format, one may use it to match the
2929 VLAN ID in all of the ways available with the OpenFlow 1.0 and 1.1 for‐
2930 mats, and a few new ways:
2931 Fully wildcarded
2933 Matches any packet, that is, one without an 802.1Q header
2934 or with an 802.1Q header with any TCI value.
2935 Value 0x0000 (OFPVID_NONE), mask 0xffff (or no mask)
2937 Matches only packets without an 802.1Q header.
2938 Value 0x1000, mask 0x1000
2940 Matches any packet with an 802.1Q header, regardless of
2941 VLAN ID.
2942 Value 0x1009, mask 0xffff (or no mask)
2944 Match only packets with an 802.1Q header with VLAN ID 9.
2945 Value 0x1001, mask 0x1001
2947 Matches only packets that have an 802.1Q header with an
2948 odd-numbered VLAN ID. (This is just an example; one can
2949 match on any desired VLAN ID bit pattern.)
2950 OpenFlow 1.2+ VLAN Priority Field
2952 Name: vlan_pcp
2954 Width: 8 bits (only the least-significant 3 bits may be nonzero)
2955 Format: decimal
2956 Masking: not maskable
2958 Prerequisites: VLAN VID
2959 Access: read/write
2960 OpenFlow 1.0: yes (exact match only)
2961 OpenFlow 1.1: yes (exact match only)
2962 OXM: OXM_OF_VLAN_PCP [22m(7) since OpenFlow 1.2 and Open vSwitch
2965 1.7
2966 NXM: none
2967 The 3 least significant bits may be used to match the PCP bits in an
2969 802.1Q header. Other bits are always zero:
2970 OXM_OF_VLAN_VID
2972 <------------->
2973 5 3
2974 +--------+------+
2975 | zero | PCP |
2976 +--------+------+
2977 0
2978 This field may only be used when vlan_vid is not wildcarded and does
2981 not exact match on 0 (which only matches when there is no 802.1Q
2982 header).
2983 See VLAN Comparison Chart, below, for some examples.
2985 Open vSwitch Extension VLAN Field
2987 The vlan_tci extension can describe more kinds of VLAN matches than the
2988 other variants. It is also simpler than the other variants.
2989 VLAN TCI Field
2991 Name: vlan_tci
2993 Width: 16 bits
2994 Format: hexadecimal
2995 Masking: arbitrary bitwise masks
2996 Prerequisites: Ethernet
2997 Access: read/write
2998 OpenFlow 1.0: yes (exact match only)
3000 OpenFlow 1.1: yes (exact match only)
3001 OXM: none
3002 NXM: NXM_OF_VLAN_TCI (4) since Open vSwitch 1.1
3003 For a packet without an 802.1Q header, this field is zero. For a packet
3005 with an 802.1Q header, this field is the TCI with the bit in CFI’s
3006 position (marked P for ``present’’ below) forced to 1. Thus, for a
3007 packet in VLAN 9 with priority 7, it has the value 0xf009:
3008 NXM_VLAN_TCI
3010 <---------->
3011 3 1 12
3012 +----+--+----+
3013 |PCP |P |VID |
3014 +----+--+----+
3015 7 1 9
3016 Usage examples:
3019 vlan_tci=0
3021 Match packets without an 802.1Q header.
3022 vlan_tci=0x1000/0x1000
3024 Match packets with an 802.1Q header, regardless of VLAN
3025 and priority values.
3026 vlan_tci=0xf123
3028 Match packets tagged with priority 7 in VLAN 0x123.
3029 vlan_tci=0x1123/0x1fff
3031 Match packets tagged with VLAN 0x123 (and any priority).
3032 vlan_tci=0x5000/0xf000
3034 Match packets tagged with priority 2 (in any VLAN).
3035 vlan_tci=0/0xfff
3037 Match packets with no 802.1Q header or tagged with VLAN 0
3038 (and any priority).
3039 vlan_tci=0x5000/0xe000
3041 Match packets with no 802.1Q header or tagged with prior‐
3042 ity 2 (in any VLAN).
3043 vlan_tci=0/0xefff
3045 Match packets with no 802.1Q header or tagged with VLAN 0
3046 and priority 0.
3047 See VLAN Comparison Chart, below, for more examples.
3049 VLAN Comparison Chart
3051 The following table describes each of several possible matching crite‐
3052 ria on 802.1Q header may be expressed with each variation of the VLAN
3053 matching fields:
3054 Criteria OpenFlow 1.0 OpenFlow 1.1 OpenFlow 1.2+ NXM
3056 _ _ _ _ _
3057 [1] ????/1,??/? ????/1,??/? 0000/0000,-- 0000/0000
3059 [2] ffff/0,??/? ffff/0,??/? 0000/ffff,-- 0000/ffff
3060 [3] 0xxx/0,??/1 0xxx/0,??/1 1xxx/ffff,-- 1xxx/1fff
3061 [4] ????/1,0y/0 fffe/0,0y/0 1000/1000,0y z000/f000
3062 [5] 0xxx/0,0y/0 0xxx/0,0y/0 1xxx/ffff,0y zxxx/ffff
3063 [6] (none) (none) 1001/1001,-- 1001/1001
3064 [7] (none) (none) (none) 3000/3000
3065 [8] (none) (none) (none) 0000/0fff
3066 [9] (none) (none) (none) 0000/f000
3067 [10] (none) (none) (none) 0000/efff
3068 All numbers in the table are expressed in hexadecimal. The columns in
3070 the table are interpreted as follows:
3071 Criteria
3073 See the list below.
3074 OpenFlow 1.0
3076 OpenFlow 1.1
3077 wwww/x,yy/z means VLAN ID match value wwww with wildcard
3078 bit x and VLAN PCP match value yy with wildcard bit z. ?
3079 means that the given bits are ignored (and conventionally 0
3080 for wwww or yy, conventionally 1 for x or z). ``(none)’’
3081 means that OpenFlow 1.0 (or 1.1) cannot match with these
3082 criteria.
3083 OpenFlow 1.2+
3085 xxxx/yyyy,zz means vlan_vid with value xxxx and mask yyyy,
3086 and vlan_pcp (which is not maskable) with value zz. --
3087 means that vlan_pcp is omitted. ``(none)’’ means that Open‐
3088 Flow 1.2 cannot match with these criteria.
3089 NXM xxxx/yyyy means vlan_tci with value xxxx and mask yyyy.
3091 The matching criteria described by the table are:
3093 [1] Matches any packet, that is, one without an 802.1Q header
3095 or with an 802.1Q header with any TCI value.
3096 [2] Matches only packets without an 802.1Q header.
3098 OpenFlow 1.0 doesn’t define the behavior if dl_vlan is
3100 set to 0xffff and dl_vlan_pcp is not wildcarded. (Open
3101 vSwitch always ignores dl_vlan_pcp when dl_vlan is set to
3102 0xffff.)
3103 OpenFlow 1.1 says explicitly to ignore dl_vlan_pcp when
3105 dl_vlan is set to 0xffff.
3106 OpenFlow 1.2 doesn’t say how to interpret a match with
3108 vlan_vid value 0 and a mask with OFPVID_PRESENT (0x1000)
3109 set to 1 and some other bits in the mask set to 1 also.
3110 Open vSwitch interprets it the same way as a mask of
3111 0x1000.
3112 Any NXM match with vlan_tci value 0 and the CFI bit set
3114 to 1 in the mask is equivalent to the one listed in the
3115 table.
3116 [3] Matches only packets that have an 802.1Q header with VID
3118 xxx (and any PCP).
3119 [4] Matches only packets that have an 802.1Q header with PCP
3121 y (and any VID).
3122 OpenFlow 1.0 doesn’t clearly define the behavior for this
3124 case. Open vSwitch implements it this way.
3125 In the NXM value, z equals (y << 1) | 1.
3127 [5] Matches only packets that have an 802.1Q header with VID
3129 xxx and PCP y.
3130 In the NXM value, z equals (y << 1) | 1.
3132 [6] Matches only packets that have an 802.1Q header with an
3134 odd-numbered VID (and any PCP). Only possible with Open‐
3135 Flow 1.2 and NXM. (This is just an example; one can match
3136 on any desired VID bit pattern.)
3137 [7] Matches only packets that have an 802.1Q header with an
3139 odd-numbered PCP (and any VID). Only possible with NXM.
3140 (This is just an example; one can match on any desired
3141 VID bit pattern.)
3142 [8] Matches packets with no 802.1Q header or with an 802.1Q
3144 header with a VID of 0. Only possible with NXM.
3145 [9] Matches packets with no 802.1Q header or with an 802.1Q
3147 header with a PCP of 0. Only possible with NXM.
3148 [10] Matches packets with no 802.1Q header or with an 802.1Q
3150 header with both VID and PCP of 0. Only possible with
3151 NXM.
3153 Summary:
3154 Name Bytes Mask RW? Prereqs NXM/OXM Support
3155 ─────────── ──────────────── ───── ──── ──────── ──────────────────────
3157 mpls_label 4 (low 20 bits) no yes MPLS OF 1.2+ and OVS 1.11+
3158 mpls_tc 1 (low 3 bits) no yes MPLS OF 1.2+ and OVS 1.11+
3159 mpls_bos 1 (low 1 bits) no no MPLS OF 1.3+ and OVS 1.11+
3161 mpls_ttl 1 no yes MPLS OVS 2.6+
3162 One or more MPLS headers (more commonly called MPLS labels) follow an
3164 Ethernet type field that specifies an MPLS Ethernet type [RFC 3032].
3165 Ethertype 0x8847 is used for all unicast. Multicast MPLS is divided
3166 into two specific classes, one of which uses Ethertype 0x8847 and the
3167 other 0x8848 [RFC 5332].
3168 The most common overall packet format is Ethernet II, shown below (SNAP
3170 encapsulation may be used but is not ordinarily seen in Ethernet net‐
3171 works):
3172 Ethernet MPLS
3174 <------------> <------------>
3175 48 48 16 20 3 1 8
3176 +---+---+------+ +-----+--+-+---+
3177 |dst|src| type | |label|TC|S|TTL| ...
3178 +---+---+------+ +-----+--+-+---+
3179 0x8847
3180 MPLS can be encapsulated inside an 802.1Q header, in which case the
3183 combination looks like this:
3184 Ethernet 802.1Q Ethertype MPLS
3186 <------> <--------> <-------> <------------>
3187 48 48 16 16 16 20 3 1 8
3188 +----+---+ +------+---+ +---------+ +-----+--+-+---+
3189 |dst |src| | TPID |TCI| | type | |label|TC|S|TTL| ...
3190 +----+---+ +------+---+ +---------+ +-----+--+-+---+
3191 0x8100 0x8847
3192 The fields within an MPLS label are:
3195 Label, 20 bits.
3197 An identifier.
3198 Traffic control (TC), 3 bits.
3200 Used for quality of service.
3201 Bottom of stack (BOS), 1 bit (labeled just ``S’’ above).
3203 0 indicates that another MPLS label follows this one.
3204 1 indicates that this MPLS label is the last one in the
3206 stack, so that some other protocol follows this one.
3207 Time to live (TTL), 8 bits.
3209 Each hop across an MPLS network decrements the TTL by 1.
3210 If it reaches 0, the packet is discarded.
3211 OpenFlow does not make the MPLS TTL available as a match
3213 field, but actions are available to set and decrement the
3214 TTL. Open vSwitch 2.6 and later makes the MPLS TTL avail‐
3215 able as an extension.
3216 MPLS Label Stacks
3218 Unlike the other encapsulations supported by OpenFlow and Open vSwitch,
3219 MPLS labels are routinely used in ``stacks’’ two or three deep and
3220 sometimes even deeper. Open vSwitch currently supports up to three
3221 labels.
3222 The OpenFlow specification only supports matching on the outermost MPLS
3224 label at any given time. To match on the second label, one must first
3225 ``pop’’ the outer label and advance to another OpenFlow table, where
3226 the inner label may be matched. To match on the third label, one must
3227 pop the two outer labels, and so on. The Open Networking Foundation is
3228 considering support for directly matching on multiple MPLS labels for
3229 OpenFlow 1.6.
3230 MPLS Inner Protocol
3232 Unlike all other forms of encapsulation that Open vSwitch and OpenFlow
3233 support, an MPLS label does not indicate what inner protocol it encap‐
3234 sulates. Different deployments determine the inner protocol in differ‐
3235 ent ways [RFC 3032]:
3236 · A few reserved label values do indicate an inner proto‐
3238 col. Label 0, the ``IPv4 Explicit NULL Label,’’ indicates
3239 inner IPv4. Label 2, the ``IPv6 Explicit NULL Label,’’
3240 indicates inner IPv6.
3241 · Some deployments use a single inner protocol consis‐
3243 tently.
3244 · In some deployments, the inner protocol must be inferred
3246 from the innermost label.
3247 · In some deployments, the inner protocol must be inferred
3249 from the innermost label and the encapsulated data, e.g.
3250 to distinguish between inner IPv4 and IPv6 based on
3251 whether the first nibble of the inner protocol data are 4
3252 or 6. OpenFlow and Open vSwitch do not currently support
3253 these cases.
3254 Open vSwitch and OpenFlow do not infer the inner protocol, even if
3256 reserved label values are in use. Instead, the flow table must specify
3257 the inner protocol at the time it pops the bottommost MPLS label, using
3258 the Ethertype argument to the pop_mpls action.
3259 Field Details
3261 MPLS Label Field
3262 Name: mpls_label
3264 Width: 32 bits (only the least-significant 20 bits may be nonzero)
3265 Format: decimal
3267 Masking: not maskable
3268 Prerequisites: MPLS
3269 Access: read/write
3270 OpenFlow 1.0: not supported
3271 OpenFlow 1.1: yes (exact match only)
3272 OXM: OXM_OF_MPLS_LABEL (34) since OpenFlow 1.2 and Open vSwitch
3275 1.11
3276 NXM: none
3277 The least significant 20 bits hold the ``label’’ field from the MPLS
3279 label. Other bits are zero:
3280 OXM_OF_MPLS_LABEL
3282 <--------------->
3283 12 20
3284 +--------+--------+
3285 | zero | label |
3286 +--------+--------+
3287 0
3288 Most label values are available for any use by deployments. Values
3291 under 16 are reserved.
3292 MPLS Traffic Class Field
3294 Name: mpls_tc
3296 Width: 8 bits (only the least-significant 3 bits may be nonzero)
3297 Format: decimal
3299 Masking: not maskable
3300 Prerequisites: MPLS
3301 Access: read/write
3302 OpenFlow 1.0: not supported
3303 OpenFlow 1.1: yes (exact match only)
3304 OXM: OXM_OF_MPLS_TC [22m(35) since OpenFlow 1.2 and Open vSwitch
3307 1.11
3308 NXM: none
3309 The least significant 3 bits hold the TC field from the MPLS label.
3311 Other bits are zero:
3312 OXM_OF_MPLS_TC
3314 <------------>
3315 5 3
3316 +--------+-----+
3317 | zero | TC |
3318 +--------+-----+
3319 0
3320 This field is intended for use for Quality of Service (QoS) and
3323 Explicit Congestion Notification purposes, but its particular interpre‐
3324 tation is deployment specific.
3325 Before 2009, this field was named EXP and reserved for experimental use
3327 [RFC 5462].
3328 MPLS Bottom of Stack Field
3330 Name: mpls_bos
3332 Width: 8 bits (only the least-significant 1 bits may be nonzero)
3333 Format: decimal
3334 Masking: not maskable
3335 Prerequisites: MPLS
3336 Access: read-only
3337 OpenFlow 1.0: not supported
3339 OpenFlow 1.1: not supported
3340 OXM: OXM_OF_MPLS_BOS (36) since OpenFlow 1.3 and Open vSwitch
3341 1.11
3342 NXM: none
3343 The least significant bit holds the BOS field from the MPLS label.
3345 Other bits are zero:
3346 OXM_OF_MPLS_BOS
3348 <------------->
3349 7 1
3350 +--------+------+
3351 | zero | BOS |
3352 +--------+------+
3353 0
3354 This field is useful as part of processing a series of incoming MPLS
3357 labels. A flow that includes a pop_mpls action should generally match
3358 on mpls_bos:
3359 · When mpls_bos is 1, there is another MPLS label following
3361 this one, so the Ethertype passed to pop_mpls should be
3362 an MPLS Ethertype. For example: table=0, dl_type=0x8847,
3363 mpls_bos=1, actions=pop_mpls:0x8847, goto_table:1
3364 · When mpls_bos is 0, this MPLS label is the last one, so
3366 the Ethertype passed to pop_mpls should be a non-MPLS
3367 Ethertype such as IPv4. For example: table=1,
3368 dl_type=0x8847, mpls_bos=0, actions=pop_mpls:0x0800,
3369 goto_table:2
3370 MPLS Time-to-Live Field
3372 Name: mpls_ttl
3374 Width: 8 bits
3375 Format: decimal
3376 Masking: not maskable
3377 Prerequisites: MPLS
3379 Access: read/write
3380 OpenFlow 1.0: not supported
3381 OpenFlow 1.1: not supported
3382 OXM: none
3383 NXM: NXM_NX_MPLS_TTL (30) since Open vSwitch 2.6
3384 Holds the 8-bit time-to-live field from the MPLS label:
3386 NXM_NX_MPLS_TTL
3388 <------------->
3389 8
3390 +---------------+
3391 | TTL |
3392 +---------------+
3393
3395 Summary:
3396 Name Bytes Mask RW? Prereqs NXM/OXM Support
3397 ────────────────────── ──────────────── ───── ──── ────────── ─────────────────────
3399 ip_src aka nw_src 4 yes yes IPv4 OF 1.2+ and OVS 1.1+
3400 ip_dst aka nw_dst 4 yes yes IPv4 OF 1.2+ and OVS 1.1+
3401 ipv6_src 16 yes yes IPv6 OF 1.2+ and OVS 1.1+
3403 ipv6_dst 16 yes yes IPv6 OF 1.2+ and OVS 1.1+
3404 ipv6_label 4 (low 20 bits) yes yes IPv6 OF 1.2+ and OVS 1.4+
3405 nw_proto aka ip_proto 1 no no IPv4/IPv6 OF 1.2+ and OVS 1.1+
3407 nw_ttl 1 no yes IPv4/IPv6 OVS 1.4+
3408 ip_frag 1 (low 2 bits) yes no IPv4/IPv6 OVS 1.3+
3409 nw_tos 1 no yes IPv4/IPv6 OVS 1.1+
3411 ip_dscp 1 (low 6 bits) no yes IPv4/IPv6 OF 1.2+ and OVS 1.7+
3412 nw_ecn aka ip_ecn 1 (low 2 bits) no yes IPv4/IPv6 OF 1.2+ and OVS 1.4+
3413 IPv4 Specific Fields
3415 These fields are applicable only to IPv4 flows, that is, flows that
3416 match on the IPv4 Ethertype 0x0800.
3417 IPv4 Source Address Field
3419 Name: ip_src (aka nw_src)
3421 Width: 32 bits
3423 Format: IPv4
3424 Masking: arbitrary bitwise masks
3425 Prerequisites: IPv4
3427 Access: read/write
3428 OpenFlow 1.0: yes (CIDR match only)
3429 OpenFlow 1.1: yes
3431 OXM: OXM_OF_IPV4_SRC [22m(11) since OpenFlow 1.2 and Open
3432 vSwitch 1.7
3433 NXM: NXM_OF_IP_SRC (7) since Open vSwitch 1.1
3435 The source address from the IPv4 header:
3437 Ethernet IPv4
3439 <-----------> <--------------->
3440 48 48 16 8 32 32
3441 +---+---+-----+ +---+-----+---+---+
3442 |dst|src|type | |...|proto|src|dst| ...
3443 +---+---+-----+ +---+-----+---+---+
3444 0x800
3445 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3448 matches on nw_src as actually referring to the ARP SPA.
3449 IPv4 Destination Address Field
3451 Name: ip_dst (aka nw_dst)
3453 Width: 32 bits
3455 Format: IPv4
3456 Masking: arbitrary bitwise masks
3457 Prerequisites: IPv4
3459 Access: read/write
3460 OpenFlow 1.0: yes (CIDR match only)
3461 OpenFlow 1.1: yes
3463 OXM: OXM_OF_IPV4_DST [22m(12) since OpenFlow 1.2 and Open
3464 vSwitch 1.7
3465 NXM: NXM_OF_IP_DST (8) since Open vSwitch 1.1
3467 The destination address from the IPv4 header:
3469 Ethernet IPv4
3471 <-----------> <--------------->
3472 48 48 16 8 32 32
3473 +---+---+-----+ +---+-----+---+---+
3474 |dst|src|type | |...|proto|src|dst| ...
3475 +---+---+-----+ +---+-----+---+---+
3476 0x800
3477 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3480 matches on nw_dst as actually referring to the ARP TPA.
3481 IPv6 Specific Fields
3483 These fields apply only to IPv6 flows, that is, flows that match on the
3484 IPv6 Ethertype 0x86dd.
3485 IPv6 Source Address Field
3487 Name: ipv6_src
3489 Width: 128 bits
3491 Format: IPv6
3492 Masking: arbitrary bitwise masks
3493 Prerequisites: IPv6
3495 Access: read/write
3496 OpenFlow 1.0: not supported
3497 OpenFlow 1.1: not supported
3499 OXM: OXM_OF_IPV6_SRC [22m(26) since OpenFlow 1.2 and Open
3500 vSwitch 1.1
3501 NXM: NXM_NX_IPV6_SRC (19) since Open vSwitch 1.1
3503 The source address from the IPv6 header:
3505 Ethernet IPv6
3507 <------------> <-------------->
3508 48 48 16 8 128 128
3509 +---+---+------+ +---+----+---+---+
3510 |dst|src| type | |...|next|src|dst| ...
3511 +---+---+------+ +---+----+---+---+
3512 0x86dd
3513 Open vSwitch 1.8 added support for bitwise matching; earlier versions
3516 supported only CIDR masks.
3517 IPv6 Destination Address Field
3519 Name: ipv6_dst
3521 Width: 128 bits
3523 Format: IPv6
3524 Masking: arbitrary bitwise masks
3525 Prerequisites: IPv6
3527 Access: read/write
3528 OpenFlow 1.0: not supported
3529 OpenFlow 1.1: not supported
3531 OXM: OXM_OF_IPV6_DST [22m(27) since OpenFlow 1.2 and Open
3532 vSwitch 1.1
3533 NXM: NXM_NX_IPV6_DST (20) since Open vSwitch 1.1
3535 The destination address from the IPv6 header:
3537 Ethernet IPv6
3539 <------------> <-------------->
3540 48 48 16 8 128 128
3541 +---+---+------+ +---+----+---+---+
3542 |dst|src| type | |...|next|src|dst| ...
3543 +---+---+------+ +---+----+---+---+
3544 0x86dd
3545 Open vSwitch 1.8 added support for bitwise matching; earlier versions
3548 supported only CIDR masks.
3549 IPv6 Flow Label Field
3551 Name: ipv6_label
3553 Width: 32 bits (only the least-significant 20 bits may be nonzero)
3555 Format: hexadecimal
3556 Masking: arbitrary bitwise masks
3557 Prerequisites: IPv6
3559 Access: read/write
3560 OpenFlow 1.0: not supported
3561 OpenFlow 1.1: not supported
3563 OXM: OXM_OF_IPV6_FLABEL (28) since OpenFlow 1.2 and Open vSwitch
3564 1.7
3565 NXM: NXM_NX_IPV6_LABEL (27) since Open vSwitch 1.4
3567 The least significant 20 bits hold the flow label field from the IPv6
3569 header. Other bits are zero:
3570 OXM_OF_IPV6_FLABEL
3572 <---------------->
3573 12 20
3574 +--------+---------+
3575 | zero | label |
3576 +--------+---------+
3577 0
3578 IPv4/IPv6 Fields
3581 These fields exist with at least approximately the same meaning in both
3582 IPv4 and IPv6, so they are treated as a single field for matching pur‐
3583 poses. Any flow that matches on the IPv4 Ethertype 0x0800 or the IPv6
3584 Ethertype 0x86dd may match on these fields.
3585 IPv4/v6 Protocol Field
3587 Name: nw_proto (aka ip_proto)
3589 Width: 8 bits
3590 Format: decimal
3591 Masking: not maskable
3592 Prerequisites: IPv4/IPv6
3594 Access: read-only
3595 OpenFlow 1.0: yes (exact match only)
3596 OpenFlow 1.1: yes (exact match only)
3597 OXM: OXM_OF_IP_PROTO [22m(10) since OpenFlow 1.2 and Open
3599 vSwitch 1.7
3600 NXM: NXM_OF_IP_PROTO (6) since Open vSwitch 1.1
3601 Matches the IPv4 or IPv6 protocol type.
3603 For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3605 matches on nw_proto as actually referring to the ARP opcode. The ARP
3606 opcode is a 16-bit field, so for matching purposes ARP opcodes greater
3607 than 255 are treated as 0; this works adequately because in practice
3608 ARP and RARP only use opcodes 1 through 4.
3609 IPv4/v6 TTL/Hop Limit Field
3611 Name: nw_ttl
3614 Width: 8 bits
3615 Format: decimal
3616 Masking: not maskable
3617 Prerequisites: IPv4/IPv6
3619 Access: read/write
3620 OpenFlow 1.0: not supported
3621 OpenFlow 1.1: not supported
3622 OXM: none
3624 NXM: NXM_NX_IP_TTL (29) since Open vSwitch 1.4
3625 The main reason to match on the TTL or hop limit field is to detect
3627 whether a dec_ttl action will fail due to a TTL exceeded error. Another
3628 way that a controller can detect TTL exceeded is to listen for
3629 OFPR_INVALID_TTL ``packet-in’’ messages via OpenFlow.
3630 IPv4/v6 Fragment Bitmask Field
3632 Name: ip_frag
3634 Width: 8 bits (only the least-significant 2 bits may be nonzero)
3635 Format: frag
3636 Masking: arbitrary bitwise masks
3637 Prerequisites: IPv4/IPv6
3639 Access: read-only
3640 OpenFlow 1.0: not supported
3641 OpenFlow 1.1: not supported
3642 OXM: none
3644 NXM: NXM_NX_IP_FRAG (26) since Open vSwitch 1.3
3645 Specifies what kinds of IP fragments or non-fragments to match. The
3647 value for this field is most conveniently specified as one of the fol‐
3648 lowing:
3649 no Match only non-fragmented packets.
3651 yes Matches all fragments.
3653 first Matches only fragments with offset 0.
3655 later Matches only fragments with nonzero offset.
3657 not_later
3659 Matches non-fragmented packets and fragments with zero
3660 offset.
3661 The field is internally formatted as 2 bits: bit 0 is 1 for an IP frag‐
3663 ment with any offset (and otherwise 0), and bit 1 is 1 for an IP frag‐
3664 ment with nonzero offset (and otherwise 0), like so:
3665 NXM_NX_IP_FRAG
3667 <------------>
3668 6 1 1
3669 +----+-----+---+
3670 |zero|later|any|
3671 +----+-----+---+
3672 0
3673 Even though 2 bits have 4 possible values, this field only uses 3 of
3676 them:
3677 · A packet that is not an IP fragment has value 0.
3679 · A packet that is an IP fragment with offset 0 (the first
3681 fragment) has bit 0 set and thus value 1.
3682 · A packet that is an IP fragment with nonzero offset has
3684 bits 0 and 1 set and thus value 3.
3685 The switch may reject matches against values that can never appear.
3687 It is important to understand how this field interacts with the Open‐
3689 Flow fragment handling mode:
3690 · In OFPC_FRAG_DROP mode, the OpenFlow switch drops all IP
3692 fragments before they reach the flow table, so every
3693 packet that is available for matching will have value 0
3694 in this field.
3695 · Open vSwitch does not implement OFPC_FRAG_REASM mode, but
3697 if it did then IP fragments would be reassembled before
3698 they reached the flow table and again every packet avail‐
3699 able for matching would always have value 0.
3700 · In OFPC_FRAG_NORMAL mode, all three values are possible,
3702 but OpenFlow 1.0 says that fragments’ transport ports are
3703 always 0, even for the first fragment, so this does not
3704 provide much extra information.
3705 · In OFPC_FRAG_NX_MATCH mode, all three values are possi‐
3707 ble. For fragments with offset 0, Open vSwitch makes L4
3708 header information available.
3709 Thus, this field is likely to be most useful for an Open vSwitch switch
3711 configured in OFPC_FRAG_NX_MATCH mode. See the description of the
3712 set-frags command in ovs-ofctl(8), for more details.
3713 IPv4/IPv6 TOS Fields
3715 IPv4 and IPv6 contain a one-byte ``type of service’’ or TOS field that
3717 has the following format:
3718 type of service
3720 <------------->
3721 6 2
3722 +--------+------+
3723 | DSCP | ECN |
3724 +--------+------+
3725 IPv4/v6 DSCP (Bits 2-7) Field
3728 Name: nw_tos
3730 Width: 8 bits
3732 Format: decimal
3733 Masking: not maskable
3734 Prerequisites: IPv4/IPv6
3735 Access: read/write
3736 OpenFlow 1.0: yes (exact match only)
3737 OpenFlow 1.1: yes (exact match only)
3739 OXM: none
3740 NXM: NXM_OF_IP_TOS (5) since Open vSwitch 1.1
3741 This field is the TOS byte with the two ECN bits cleared to 0:
3743 NXM_OF_IP_TOS
3745 <----------->
3746 6 2
3747 +------+------+
3748 | DSCP | zero |
3749 +------+------+
3750 0
3751 IPv4/v6 DSCP (Bits 0-5) Field
3754 Name: ip_dscp
3756 Width: 8 bits (only the least-significant 6 bits may be nonzero)
3757 Format: decimal
3758 Masking: not maskable
3760 Prerequisites: IPv4/IPv6
3761 Access: read/write
3762 OpenFlow 1.0: yes (exact match only)
3763 OpenFlow 1.1: yes (exact match only)
3764 OXM: OXM_OF_IP_DSCP [22m(8) since OpenFlow 1.2 and Open vSwitch
3767 1.7
3768 NXM: none
3769 This field is the TOS byte shifted right to put the DSCP bits in the 6
3771 least-significant bits:
3772 OXM_OF_IP_DSCP
3774 <------------>
3775 2 6
3776 +-------+------+
3777 | zero | DSCP |
3778 +-------+------+
3779 0
3780 IPv4/v6 ECN Field
3783 Name: nw_ecn (aka ip_ecn)
3785 Width: 8 bits (only the least-significant 2 bits may be nonzero)
3786 Format: decimal
3788 Masking: not maskable
3789 Prerequisites: IPv4/IPv6
3790 Access: read/write
3791 OpenFlow 1.0: not supported
3792 OpenFlow 1.1: yes (exact match only)
3793 OXM: OXM_OF_IP_ECN (9) since OpenFlow 1.2 and Open vSwitch 1.7
3795 NXM: NXM_NX_IP_ECN (28) since Open vSwitch 1.4
3796 This field is the TOS byte with the DSCP bits cleared to 0:
3798 OXM_OF_IP_ECN
3800 <----------->
3801 6 2
3802 +-------+-----+
3803 | zero | ECN |
3804 +-------+-----+
3805 0
3806
3809 Summary:
3810 Name Bytes Mask RW? Prereqs NXM/OXM Support
3811 ──────── ────── ───── ──── ──────── ─────────────────────
3812 arp_op 2 no yes ARP OF 1.2+ and OVS 1.1+
3814 arp_spa 4 yes yes ARP OF 1.2+ and OVS 1.1+
3815 arp_tpa 4 yes yes ARP OF 1.2+ and OVS 1.1+
3816 arp_sha 6 yes yes ARP OF 1.2+ and OVS 1.1+
3817 arp_tha 6 yes yes ARP OF 1.2+ and OVS 1.1+
3818 In theory, Address Resolution Protocol, or ARP, is a generic protocol
3820 generic protocol that can be used to obtain the hardware address that
3821 corresponds to any higher-level protocol address. In contemporary
3822 usage, ARP is used only in Ethernet networks to obtain the Ethernet
3823 address for a given IPv4 address. OpenFlow and Open vSwitch only sup‐
3824 port this usage of ARP. For this use case, an ARP packet has the fol‐
3825 lowing format, with the ARP fields exposed as Open vSwitch fields high‐
3826 lighted:
3827 Ethernet ARP
3829 <-----------> <---------------------------------->
3830 48 48 16 16 16 8 8 16 48 16 48 16
3831 +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3832 |dst|src|type | |hrd| pro |hln|pln|op|sha|spa|tha|tpa|
3833 +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3834 0x806 1 0x800 6 4
3835 The ARP fields are also used for RARP, the Reverse Address Resolution
3838 Protocol, which shares ARP’s wire format.
3839 ARP Opcode Field
3841 Name: arp_op
3844 Width: 16 bits
3845 Format: decimal
3846 Masking: not maskable
3847 Prerequisites: ARP
3848 Access: read/write
3850 OpenFlow 1.0: yes (exact match only)
3851 OpenFlow 1.1: yes (exact match only)
3852 OXM: OXM_OF_ARP_OP (21) since OpenFlow 1.2 and Open vSwitch
3853 1.7
3854 NXM: NXM_OF_ARP_OP (15) since Open vSwitch 1.1
3856 Even though this is a 16-bit field, Open vSwitch does not support ARP
3858 opcodes greater than 255; it treats them to zero. This works adequately
3859 because in practice ARP and RARP only use opcodes 1 through 4.
3860 ARP Source IPv4 Address Field
3862 Name: arp_spa
3864 Width: 32 bits
3865 Format: IPv4
3866 Masking: arbitrary bitwise masks
3868 Prerequisites: ARP
3869 Access: read/write
3870 OpenFlow 1.0: yes (CIDR match only)
3871 OpenFlow 1.1: yes
3872 OXM: OXM_OF_ARP_SPA [22m(22) since OpenFlow 1.2 and Open
3874 vSwitch 1.7
3875 NXM: NXM_OF_ARP_SPA (16) since Open vSwitch 1.1
3876 ARP Target IPv4 Address Field
3878 Name: arp_tpa
3880 Width: 32 bits
3881 Format: IPv4
3882 Masking: arbitrary bitwise masks
3883 Prerequisites: ARP
3884 Access: read/write
3886 OpenFlow 1.0: yes (CIDR match only)
3887 OpenFlow 1.1: yes
3888 OXM: OXM_OF_ARP_TPA [22m(23) since OpenFlow 1.2 and Open
3889 vSwitch 1.7
3890 NXM: NXM_OF_ARP_TPA (17) since Open vSwitch 1.1
3892 ARP Source Ethernet Address Field
3894 Name: arp_sha
3896 Width: 48 bits
3898 Format: Ethernet
3899 Masking: arbitrary bitwise masks
3900 Prerequisites: ARP
3901 Access: read/write
3902 OpenFlow 1.0: not supported
3904 OpenFlow 1.1: not supported
3905 OXM: OXM_OF_ARP_SHA [22m(24) since OpenFlow 1.2 and Open
3906 vSwitch 1.7
3907 NXM: NXM_NX_ARP_SHA (17) since Open vSwitch 1.1
3908 ARP Target Ethernet Address Field
3910 Name: arp_tha
3912 Width: 48 bits
3913 Format: Ethernet
3914 Masking: arbitrary bitwise masks
3916 Prerequisites: ARP
3917 Access: read/write
3918 OpenFlow 1.0: not supported
3919 OpenFlow 1.1: not supported
3920 OXM: OXM_OF_ARP_THA [22m(25) since OpenFlow 1.2 and Open
3922 vSwitch 1.7
3923 NXM: NXM_NX_ARP_THA (18) since Open vSwitch 1.1
3924
3926 Summary:
3927 Name Bytes Mask RW? Prereqs NXM/OXM Support
3928 ───────────────── ──────────────── ───── ──── ──────── ────────────────
3930 nsh_flags 1 yes yes NSH OVS 2.8+
3931 nsh_ttl 1 no yes NSH OVS 2.9+
3932 nsh_mdtype 1 no no NSH OVS 2.8+
3933 nsh_np 1 no no NSH OVS 2.8+
3935 nsh_spi aka nsp 4 (low 24 bits) no yes NSH OVS 2.8+
3936 nsh_si aka nsi 1 no yes NSH OVS 2.8+
3937 nsh_c1 aka nshc1 4 yes yes NSH OVS 2.8+
3938 nsh_c2 aka nshc2 4 yes yes NSH OVS 2.8+
3940 nsh_c3 aka nshc3 4 yes yes NSH OVS 2.8+
3941 nsh_c4 aka nshc4 4 yes yes NSH OVS 2.8+
3942 Service functions are widely deployed and essential in many networks.
3944 These service functions provide a range of features such as security,
3945 WAN acceleration, and server load balancing. Service functions may be
3946 instantiated at different points in the network infrastructure such as
3947 the wide area network, data center, and so forth.
3948 Prior to development of the SFC architecture [RFC 7665] and the proto‐
3950 col specified in this document, current service function deployment
3951 models have been relatively static and bound to topology for insertion
3952 and policy selection. Furthermore, they do not adapt well to elastic
3953 service environments enabled by virtualization.
3954 New data center network and cloud architectures require more flexible
3956 service function deployment models. Additionally, the transition to
3957 virtual platforms demands an agile service insertion model that sup‐
3958 ports dynamic and elastic service delivery. Specifically, the following
3959 functions are necessary:
3960 1.
3962 The movement of service functions and application workloads in
3963 the network.
3964 2.
3966 The ability to easily bind service policy to granular informa‐
3967 tion, such as per-subscriber state.
3968 3.
3970 The capability to steer traffic to the requisite service func‐
3971 tion(s).
3972 The Network Service Header (NSH) specification defines a new data plane
3974 protocol, which is an encapsulation for service function chains. The
3975 NSH is designed to encapsulate an original packet or frame, and in turn
3976 be encapsulated by an outer transport encapsulation (which is used to
3977 deliver the NSH to NSH-aware network elements), as shown below:
3978 +-----------------------+----------------------------+---------------------+
3980 |Transport Encapsulation|Network Service Header (NSH)|Original Packet/Frame|
3981 +-----------------------+----------------------------+---------------------+
3982 The NSH is composed of the following elements:
3985 1.
3987 Service Function Path identification.
3988 2.
3990 Indication of location within a Service Function Path.
3991 3.
3993 Optional, per packet metadata (fixed length or variable).
3994 [RFC 7665] provides an overview of a service chaining architecture that
3996 clearly defines the roles of the various elements and the scope of a
3997 service function chaining encapsulation. Figure 3 of [RFC 7665] depicts
3998 the SFC architectural components after classification. The NSH is the
3999 SFC encapsulation referenced in [RFC 7665].
4000 flags field (2 bits) Field
4002 Name: nsh_flags
4004 Width: 8 bits
4005 Format: decimal
4006 Masking: arbitrary bitwise masks
4008 Prerequisites: NSH
4009 Access: read/write
4010 OpenFlow 1.0: not supported
4011 OpenFlow 1.1: not supported
4012 OXM: none
4014 NXM: NXOXM_NSH_FLAGS (1) since Open vSwitch 2.8
4015 TTL field (6 bits) Field
4017 Name: nsh_ttl
4020 Width: 8 bits
4021 Format: decimal
4022 Masking: not maskable
4023 Prerequisites: NSH
4024 Access: read/write
4026 OpenFlow 1.0: not supported
4027 OpenFlow 1.1: not supported
4028 OXM: none
4029 NXM: NXOXM_NSH_TTL (10) since Open vSwitch 2.9
4030 mdtype field (8 bits) Field
4032 Name: nsh_mdtype
4034 Width: 8 bits
4035 Format: decimal
4036 Masking: not maskable
4038 Prerequisites: NSH
4039 Access: read-only
4040 OpenFlow 1.0: not supported
4041 OpenFlow 1.1: not supported
4042 OXM: none
4044 NXM: NXOXM_NSH_MDTYPE (2) since Open vSwitch 2.8
4045 np (next protocol) field (8 bits) Field
4047 Name: nsh_np
4050 Width: 8 bits
4051 Format: decimal
4052 Masking: not maskable
4053 Prerequisites: NSH
4054 Access: read-only
4056 OpenFlow 1.0: not supported
4057 OpenFlow 1.1: not supported
4058 OXM: none
4059 NXM: NXOXM_NSH_NP (3) since Open vSwitch 2.8
4060 spi (service path identifier) field (24 bits) Field
4062 Name: nsh_spi (aka nsp)
4064 Width: 32 bits (only the least-significant 24 bits may be nonzero)
4065 Format: hexadecimal
4066 Masking: not maskable
4068 Prerequisites: NSH
4069 Access: read/write
4070 OpenFlow 1.0: not supported
4071 OpenFlow 1.1: not supported
4072 OXM: none
4074 NXM: NXOXM_NSH_SPI (4) since Open vSwitch 2.8
4075 si (service index) field (8 bits) Field
4077 Name: nsh_si (aka nsi)
4080 Width: 8 bits
4081 Format: decimal
4082 Masking: not maskable
4083 Prerequisites: NSH
4084 Access: read/write
4086 OpenFlow 1.0: not supported
4087 OpenFlow 1.1: not supported
4088 OXM: none
4089 NXM: NXOXM_NSH_SI (5) since Open vSwitch 2.8
4090 c1 (Network Platform Context) field (32 bits) Field
4092 Name: nsh_c1 (aka nshc1)
4094 Width: 32 bits
4095 Format: hexadecimal
4096 Masking: arbitrary bitwise masks
4098 Prerequisites: NSH
4099 Access: read/write
4100 OpenFlow 1.0: not supported
4101 OpenFlow 1.1: not supported
4102 OXM: none
4104 NXM: NXOXM_NSH_C1 (6) since Open vSwitch 2.8
4105 c2 (Network Shared Context) field (32 bits) Field
4107 Name: nsh_c2 (aka nshc2)
4110 Width: 32 bits
4111 Format: hexadecimal
4112 Masking: arbitrary bitwise masks
4113 Prerequisites: NSH
4114 Access: read/write
4116 OpenFlow 1.0: not supported
4117 OpenFlow 1.1: not supported
4118 OXM: none
4119 NXM: NXOXM_NSH_C2 (7) since Open vSwitch 2.8
4120 c3 (Service Platform Context) field (32 bits) Field
4122 Name: nsh_c3 (aka nshc3)
4124 Width: 32 bits
4125 Format: hexadecimal
4126 Masking: arbitrary bitwise masks
4128 Prerequisites: NSH
4129 Access: read/write
4130 OpenFlow 1.0: not supported
4131 OpenFlow 1.1: not supported
4132 OXM: none
4134 NXM: NXOXM_NSH_C3 (8) since Open vSwitch 2.8
4135 c4 (Service Shared Context) field (32 bits) Field
4137 Name: nsh_c4 (aka nshc4)
4140 Width: 32 bits
4141 Format: hexadecimal
4142 Masking: arbitrary bitwise masks
4143 Prerequisites: NSH
4144 Access: read/write
4146 OpenFlow 1.0: not supported
4147 OpenFlow 1.1: not supported
4148 OXM: none
4149 NXM: NXOXM_NSH_C4 (9) since Open vSwitch 2.8
4150
4152 Summary:
4153 Name Bytes Mask RW? Prereqs NXM/OXM Support
4154 ─────────────────── ──────────────── ───── ──── ──────── ─────────────────────
4156 tcp_src aka tp_src 2 yes yes TCP OF 1.2+ and OVS 1.1+
4157 tcp_dst aka tp_dst 2 yes yes TCP OF 1.2+ and OVS 1.1+
4158 tcp_flags 2 (low 12 bits) yes no TCP OF 1.3+ and OVS 2.1+
4159 udp_src 2 yes yes UDP OF 1.2+ and OVS 1.1+
4161 udp_dst 2 yes yes UDP OF 1.2+ and OVS 1.1+
4162 sctp_src 2 yes yes SCTP OF 1.2+ and OVS 2.0+
4163 sctp_dst 2 yes yes SCTP OF 1.2+ and OVS 2.0+
4164 For matching purposes, no distinction is made whether these protocols
4166 are encapsulated within IPv4 or IPv6.
4167 TCP
4169 The following diagram shows TCP within IPv4. Open vSwitch also supports
4170 TCP in IPv6. Only TCP fields implemented as Open vSwitch fields are
4171 shown:
4172 Ethernet IPv4 TCP
4174 <-----------> <---------------> <------------------->
4175 48 48 16 8 32 32 16 16 12
4176 +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4177 |dst|src|type | |...|proto|src|dst| |src|dst|...|flags|...| ...
4178 +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4179 0x800 6
4180 TCP Source Port Field
4183 Name: tcp_src (aka tp_src)
4185 Width: 16 bits
4186 Format: decimal
4187 Masking: arbitrary bitwise masks
4188 Prerequisites: TCP
4190 Access: read/write
4191 OpenFlow 1.0: yes (exact match only)
4192 OpenFlow 1.1: yes (exact match only)
4193 OXM: OXM_OF_TCP_SRC [22m(13) since OpenFlow 1.2 and Open
4196 vSwitch 1.7
4197 NXM: NXM_OF_TCP_SRC (9) since Open vSwitch 1.1
4198 Open vSwitch 1.6 added support for bitwise matching.
4200 TCP Destination Port Field
4202 Name: tcp_dst (aka tp_dst)
4204 Width: 16 bits
4205 Format: decimal
4206 Masking: arbitrary bitwise masks
4208 Prerequisites: TCP
4209 Access: read/write
4210 OpenFlow 1.0: yes (exact match only)
4211 OpenFlow 1.1: yes (exact match only)
4212 OXM: OXM_OF_TCP_DST [22m(14) since OpenFlow 1.2 and Open
4214 vSwitch 1.7
4215 NXM: NXM_OF_TCP_DST (10) since Open vSwitch 1.1
4216 Open vSwitch 1.6 added support for bitwise matching.
4218 TCP Flags Field
4220 Name: tcp_flags
4222 Width: 16 bits (only the least-significant 12 bits may be nonzero)
4223 Format: TCP flags
4224 Masking: arbitrary bitwise masks
4226 Prerequisites: TCP
4227 Access: read-only
4228 OpenFlow 1.0: not supported
4229 OpenFlow 1.1: not supported
4230 OXM: ONFOXM_ET_TCP_FLAGS [22m(42) since OpenFlow 1.3 and Open
4232 vSwitch 2.4; OXM_OF_TCP_FLAGS (42) since OpenFlow 1.5 and
4233 Open vSwitch 2.3
4234 NXM: NXM_NX_TCP_FLAGS (34) since Open vSwitch 2.1
4235 This field holds the TCP flags. TCP currently defines 9 flag bits. An
4237 additional 3 bits are reserved. For more information, see [RFC 793],
4238 [RFC 3168], and [RFC 3540].
4239 Matches on this field are most conveniently written in terms of sym‐
4241 bolic names (given in the diagram below), each preceded by either + for
4242 a flag that must be set, or - for a flag that must be unset, without
4243 any other delimiters between the flags. Flags not mentioned are wild‐
4244 carded. For example, tcp,tcp_flags=+syn-ack matches TCP SYNs that are
4245 not ACKs, and tcp,tcp_flags=+[200] matches TCP packets with the
4246 reserved [200] flag set. Matches can also be written as flags/mask,
4247 where flags and mask are 16-bit numbers in decimal or in hexadecimal
4248 prefixed by 0x.
4249 The flag bits are:
4251 reserved later RFCs RFC 793
4253 <---------------> <--------> <--------------------->
4254 4 1 1 1 1 1 1 1 1 1 1 1 1
4255 +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4256 |zero|[800]|[400]|[200]|NS|CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|
4257 +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4258 0
4259 UDP
4262 The following diagram shows UDP within IPv4. Open vSwitch also supports
4263 UDP in IPv6. Only UDP fields that Open vSwitch exposes as fields are
4264 shown:
4265 Ethernet IPv4 UDP
4267 <-----------> <---------------> <--------->
4268 48 48 16 8 32 32 16 16
4269 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4270 |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4271 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4272 0x800 17
4273 UDP Source Port Field
4276 Name: udp_src
4278 Width: 16 bits
4280 Format: decimal
4281 Masking: arbitrary bitwise masks
4282 Prerequisites: UDP
4283 Access: read/write
4284 OpenFlow 1.0: yes (exact match only)
4286 OpenFlow 1.1: yes (exact match only)
4287 OXM: OXM_OF_UDP_SRC [22m(15) since OpenFlow 1.2 and Open
4288 vSwitch 1.7
4289 NXM: NXM_OF_UDP_SRC (11) since Open vSwitch 1.1
4290 UDP Destination Port Field
4292 Name: udp_dst
4294 Width: 16 bits
4295 Format: decimal
4296 Masking: arbitrary bitwise masks
4298 Prerequisites: UDP
4299 Access: read/write
4300 OpenFlow 1.0: yes (exact match only)
4301 OpenFlow 1.1: yes (exact match only)
4302 OXM: OXM_OF_UDP_DST [22m(16) since OpenFlow 1.2 and Open
4304 vSwitch 1.7
4305 NXM: NXM_OF_UDP_DST (12) since Open vSwitch 1.1
4306 SCTP
4308 The following diagram shows SCTP within IPv4. Open vSwitch also sup‐
4309 ports SCTP in IPv6. Only SCTP fields that Open vSwitch exposes as
4310 fields are shown:
4311 Ethernet IPv4 SCTP
4313 <-----------> <---------------> <--------->
4314 48 48 16 8 32 32 16 16
4315 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4316 |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4317 +---+---+-----+ +---+-----+---+---+ +---+---+---+
4318 0x800 132
4319 SCTP Source Port Field
4322 Name: sctp_src
4325 Width: 16 bits
4326 Format: decimal
4327 Masking: arbitrary bitwise masks
4328 Prerequisites: SCTP
4329 Access: read/write
4330 OpenFlow 1.0: not supported
4332 OpenFlow 1.1: yes (exact match only)
4333 OXM: OXM_OF_SCTP_SRC [22m(17) since OpenFlow 1.2 and Open
4334 vSwitch 2.0
4335 NXM: none
4336 SCTP Destination Port Field
4338 Name: sctp_dst
4340 Width: 16 bits
4341 Format: decimal
4342 Masking: arbitrary bitwise masks
4343 Prerequisites: SCTP
4344 Access: read/write
4346 OpenFlow 1.0: not supported
4347 OpenFlow 1.1: yes (exact match only)
4348 OXM: OXM_OF_SCTP_DST [22m(18) since OpenFlow 1.2 and Open
4349 vSwitch 2.0
4350 NXM: none
4351
4353 Summary:
4354 Name Bytes Mask RW? Prereqs NXM/OXM Support
4355 ──────────── ────── ───── ──── ─────────── ─────────────────────
4356 icmp_type 1 no yes ICMPv4 OF 1.2+ and OVS 1.1+
4358 icmp_code 1 no yes ICMPv4 OF 1.2+ and OVS 1.1+
4359 icmpv6_type 1 no yes ICMPv6 OF 1.2+ and OVS 1.1+
4360 icmpv6_code 1 no yes ICMPv6 OF 1.2+ and OVS 1.1+
4361 nd_target 16 yes yes ND OF 1.2+ and OVS 1.1+
4362 nd_sll 6 yes yes ND solicit OF 1.2+ and OVS 1.1+
4364 nd_tll 6 yes yes ND advert OF 1.2+ and OVS 1.1+
4365 ICMPv4
4367 Ethernet IPv4 ICMPv4
4368 <-----------> <---------------> <----------->
4369 48 48 16 8 32 32 8 8
4370 +---+---+-----+ +---+-----+---+---+ +----+----+---+
4371 |dst|src|type | |...|proto|src|dst| |type|code|...| ...
4372 +---+---+-----+ +---+-----+---+---+ +----+----+---+
4373 0x800 1
4374 ICMPv4 Type Field
4377 Name: icmp_type
4379 Width: 8 bits
4380 Format: decimal
4382 Masking: not maskable
4383 Prerequisites: ICMPv4
4384 Access: read/write
4385 OpenFlow 1.0: yes (exact match only)
4386 OpenFlow 1.1: yes (exact match only)
4388 OXM: OXM_OF_ICMPV4_TYPE (19) since OpenFlow 1.2 and Open
4389 vSwitch 1.7
4390 NXM: NXM_OF_ICMP_TYPE (13) since Open vSwitch 1.1
4391 For historical reasons, in an ICMPv4 flow, Open vSwitch interprets
4393 matches on tp_src as actually referring to the ICMP type.
4394 ICMPv4 Code Field
4396 Name: icmp_code
4398 Width: 8 bits
4400 Format: decimal
4401 Masking: not maskable
4402 Prerequisites: ICMPv4
4403 Access: read/write
4404 OpenFlow 1.0: yes (exact match only)
4406 OpenFlow 1.1: yes (exact match only)
4407 OXM: OXM_OF_ICMPV4_CODE (20) since OpenFlow 1.2 and Open
4408 vSwitch 1.7
4409 NXM: NXM_OF_ICMP_CODE (14) since Open vSwitch 1.1
4410 For historical reasons, in an ICMPv4 flow, Open vSwitch interprets
4412 matches on tp_dst as actually referring to the ICMP code.
4413 ICMPv6
4415 Ethernet IPv6 ICMPv6
4416 <------------> <--------------> <----------->
4417 48 48 16 8 128 128 8 8
4418 +---+---+------+ +---+----+---+---+ +----+----+---+
4419 |dst|src| type | |...|next|src|dst| |type|code|...| ...
4420 +---+---+------+ +---+----+---+---+ +----+----+---+
4421 0x86dd 58
4422 ICMPv6 Type Field
4425 Name: icmpv6_type
4427 Width: 8 bits
4428 Format: decimal
4430 Masking: not maskable
4431 Prerequisites: ICMPv6
4432 Access: read/write
4433 OpenFlow 1.0: not supported
4434 OpenFlow 1.1: not supported
4436 OXM: OXM_OF_ICMPV6_TYPE (29) since OpenFlow 1.2 and Open
4437 vSwitch 1.7
4438 NXM: NXM_NX_ICMPV6_TYPE (21) since Open vSwitch 1.1
4439 ICMPv6 Code Field
4441 Name: icmpv6_code
4443 Width: 8 bits
4444 Format: decimal
4445 Masking: not maskable
4446 Prerequisites: ICMPv6
4448 Access: read/write
4449 OpenFlow 1.0: not supported
4450 OpenFlow 1.1: not supported
4451 OXM: OXM_OF_ICMPV6_CODE [22m(30) since OpenFlow 1.2 and Open
4454 vSwitch 1.7
4455 NXM: NXM_NX_ICMPV6_CODE (22) since Open vSwitch 1.1
4456 ICMPv6 Neighbor Discovery
4458 Ethernet IPv6 ICMPv6 ICMPv6 ND
4459 <------------> <--------------> <--------------> <--------------->
4460 48 48 16 8 128 128 8 8 128
4461 +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4462 |dst|src| type | |...|next|src|dst| | type |code|...| |target|option ...|
4463 +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4464 0x86dd 58 135/136 0
4465 ICMPv6 Neighbor Discovery Target IPv6 Field
4468 Name: nd_target
4470 Width: 128 bits
4471 Format: IPv6
4472 Masking: arbitrary bitwise masks
4473 Prerequisites: ND
4475 Access: read/write
4476 OpenFlow 1.0: not supported
4477 OpenFlow 1.1: not supported
4478 OXM: OXM_OF_IPV6_ND_TARGET (31) since OpenFlow 1.2 and Open
4479 vSwitch 1.7
4480 NXM: NXM_NX_ND_TARGET (23) since Open vSwitch 1.1
4482 ICMPv6 Neighbor Discovery Source Ethernet Address Field
4484 Name: nd_sll
4486 Width: 48 bits
4487 Format: Ethernet
4489 Masking: arbitrary bitwise masks
4490 Prerequisites: ND solicit
4491 Access: read/write
4492 OpenFlow 1.0: not supported
4493 OpenFlow 1.1: not supported
4494 OXM: OXM_OF_IPV6_ND_SLL [22m(32) since OpenFlow 1.2 and Open
4496 vSwitch 1.7
4497 NXM: NXM_NX_ND_SLL (24) since Open vSwitch 1.1
4498 ICMPv6 Neighbor Discovery Target Ethernet Address Field
4500 Name: nd_tll
4503 Width: 48 bits
4504 Format: Ethernet
4505 Masking: arbitrary bitwise masks
4506 Prerequisites: ND advert
4507 Access: read/write
4508 OpenFlow 1.0: not supported
4510 OpenFlow 1.1: not supported
4511 OXM: OXM_OF_IPV6_ND_TLL (33) since OpenFlow 1.2 and Open
4512 vSwitch 1.7
4513 NXM: NXM_NX_ND_TLL (25) since Open vSwitch 1.1
4514
4516 Casado M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown,
4517 and S. Shenker, ``Ethane: Taking Control of the Enter‐
4518 prise,’’ Computer Communications Review, October 2007.
4519 ERSPAN M. Foschiano, K. Ghosh, M. Mehta, ``Cisco Systems’ Encap‐
4521 sulated Remote Switch Port Analyzer (ERSPAN),’’ ⟨https://
4522 tools.ietf.org/html/draft-foschiano-erspan-03⟩ .
4523 EXT-56 J. Tonsing, ``Permit one of a set of prerequisites to
4525 apply, e.g. don’t preclude non-Ethernet media,’’
4526 ⟨https://rs.opennetworking.org/bugs/browse/EXT-56⟩ (ONF
4527 members only).
4528 EXT-112
4530 J. Tourrilhes, ``Support non-Ethernet packets throughout
4531 the pipeline,’’ ⟨https://rs.opennetworking.org/bugs/
4532 browse/EXT-112⟩ (ONF members only).
4533 EXT-134
4535 J. Tourrilhes, ``Match first nibble of the MPLS pay‐
4536 load,’’ ⟨https://rs.opennetworking.org/bugs/browse/
4537 EXT-134⟩ (ONF members only).
4538 Geneve J. Gross, I. Ganga, and T. Sridhar, editors, ``Geneve:
4540 Generic Network Virtualization Encapsulation,’’ ⟨https://
4541 datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/⟩ .
4542 IEEE OUI
4544 IEEE Standards Association, ``MAC Address Block Large
4545 (MA-L),’’ ⟨https://standards.ieee.org/develop/regauth/
4546 oui/index.html⟩ .
4547 NSH P. Quinn and U. Elzur, editors, ``Network Service
4549 Header,’’ ⟨https://datatracker.ietf.org/doc/
4550 draft-ietf-sfc-nsh/⟩ .
4551 OpenFlow 1.0.1
4553 Open Networking Foundation, ``OpenFlow Switch Errata,
4554 Version 1.0.1,’’ June 2012.
4555 OpenFlow 1.1
4557 OpenFlow Consortium, ``OpenFlow Switch Specification Ver‐
4558 sion 1.1.0 Implemented (Wire Protocol 0x02),’’ February
4559 2011.
4560 OpenFlow 1.5
4562 Open Networking Foundation, ``OpenFlow Switch Specifica‐
4563 tion Version 1.5.0 (Protocol version 0x06),’’ December
4564 2014.
4565 OpenFlow Extensions 1.3.x Package 2
4567 Open Networking Foundation, ``OpenFlow Extensions 1.3.x
4568 Package 2,’’ December 2013.
4569 TCP Flags Match Field Extension
4571 Open Networking Foundation, ``TCP flags match field
4572 Extension,’’ December 2014. In [OpenFlow Extensions 1.3.x
4573 Package 2].
4574 Pepelnjak
4576 I. Pepelnjak, ``OpenFlow and Fermi Estimates,’’ ⟨http://
4577 blog.ipspace.net/2013/09/openflow-and-fermi-esti‐
4578 mates.html⟩ .
4579 RFC 793
4581 ``Transmission Control Protocol,’’ ⟨http://www.ietf.org/
4582 rfc/rfc793.txt⟩ .
4583 RFC 3032
4585 E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Fari‐
4586 nacci, T. Li, and A. Conta, ``MPLS Label Stack Encod‐
4587 ing,’’ ⟨http://www.ietf.org/rfc/rfc3032.txt⟩ .
4588 RFC 3168
4590 K. Ramakrishnan, S. Floyd, and D. Black, ``The Addition
4591 of Explicit Congestion Notification (ECN) to IP,’’
4592 ⟨https://tools.ietf.org/html/rfc3168⟩ .
4593 RFC 3540
4595 N. Spring, D. Wetherall, and D. Ely, ``Robust Explicit
4596 Congestion Notification (ECN) Signaling with Nonces,’’
4597 ⟨https://tools.ietf.org/html/rfc3540⟩ .
4598 RFC 4632
4600 V. Fuller and T. Li, ``Classless Inter-domain Routing
4601 (CIDR): The Internet Address Assignment and Aggregation
4602 Plan,’’ ⟨https://tools.ietf.org/html/rfc4632⟩ .
4603 RFC 5462
4605 L. Andersson and R. Asati, ``Multiprotocol Label Switch‐
4606 ing (MPLS) Label Stack Entry: ``EXP’’ Field Renamed to
4607 ``Traffic Class’’ Field,’’ ⟨http://www.ietf.org/rfc/
4608 rfc5462.txt⟩ .
4609 RFC 6830
4611 D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, ``The
4612 Locator/ID Separation Protocol (LISP),’’ ⟨http://
4613 www.ietf.org/rfc/rfc6830.txt⟩ .
4614 RFC 7348
4616 M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger,
4617 T. Sridhar, M. Bursell, and C. Wright, ``Virtual eXtensi‐
4618 ble Local Area Network (VXLAN): A Framework for Overlay‐
4619 ing Virtualized Layer 2 Networks over Layer 3 Networks,
4620 ’’ ⟨https://tools.ietf.org/html/rfc7348⟩ .
4621 RFC 7665
4623 J. Halpern, Ed. and C. Pignataro, Ed., ``Service Function
4624 Chaining (SFC) Architecture,’’ ⟨https://tools.ietf.org/
4625 html/rfc7665⟩ .
4626 Srinivasan
4628 V. Srinivasan, S. Suriy, and G. Varghese, ``Packet Clas‐
4629 sification using Tuple Space Search,’’ SIGCOMM 1999.
4630 Pagiamtzis
4632 K. Pagiamtzis and A. Sheikholeslami, ``Content-address‐
4633 able memory (CAM) circuits and architectures: A tutorial
4634 and survey,’’ IEEE Journal of Solid-State Circuits, vol.
4635 41, no. 3, pp. 712-727, March 2006.
4636 VXLAN Group Policy Option
4638 M. Smith and L. Kreeger, `` VXLAN Group Policy Option.’’
4639 Internet-Draft. ⟨https://tools.ietf.org/html/
4640 draft-smith-vxlan-group-policy⟩ .
4641
4643 Ben Pfaff, with advice from Justin Pettit and Jean Tourrilhes.
4644Open vSwitch 2.10.0 ovs-fields(7)