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