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