1ovs-fields(7)                 Open vSwitch Manual                ovs-fields(7)
2
3
4

NAME

6       ovs-fields - protocol header fields in OpenFlow and Open vSwitch
7

INTRODUCTION

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

FIELDS REFERENCE

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

CONJUNCTIVE MATCH FIELDS

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

TUNNEL FIELDS

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

METADATA FIELDS

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  (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  (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

CONNECTION TRACKING FIELDS

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

REGISTER FIELDS

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   (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   (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

LAYER 2 (ETHERNET) FIELDS

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  (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

VLAN FIELDS

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
2926PCP (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
2931CFI (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
2937VID (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  (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.

LAYER 2.5: MPLS FIELDS

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  (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

LAYER 3: IPV4 AND IPV6 FIELDS

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  (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  (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  (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  (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  (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  (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

LAYER 3: ARP FIELDS

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   (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  (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   (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  (25)  since  OpenFlow  1.2  and   Open
3999                        vSwitch 1.7
4000       NXM:             NXM_NX_ARP_THA (18) since Open vSwitch 1.1
4001

LAYER 3: NSH FIELDS

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

LAYER 4: TCP, UDP, AND SCTP FIELDS

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   (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  (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   (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   (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  (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  (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  (18)  since  OpenFlow  1.2  and  Open
4419                        vSwitch 2.0
4420       NXM:             none
4421

LAYER 4: ICMPV4 AND ICMPV6 FIELDS

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  (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  (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  (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  (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   (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

REFERENCES

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,’’
4696https://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,’’
4701https://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

AUTHORS

4747       Ben Pfaff, with advice from Justin Pettit and Jean Tourrilhes.
4748
4749
4750
4751Open vSwitch                        2.17.0                       ovs-fields(7)
Impressum