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,
11       regardless 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
40       options:packet_type to ptap in the Interface table. This is significant
41       only for ports that can handle non-Ethernet packets, which is currently
42       just  LISP, VXLAN-GPE, and GRE tunnel ports. See ovs-vwitchd.conf.db(5)
43       for more information.
44
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
61       includes the field’s prerequisite, e.g. matching an ARP field  is  only
62       allowed  if one also matches on Ethertype 0x0806 or the packet_type for
63       ARP in a packet type-aware bridge.
64
65       Sometimes a packet may contain multiple  instances  of  a  header.  For
66       example,  a  packet may contain multiple VLAN or MPLS headers, and tun‐
67       nels can cause any data field to recur. OpenFlow and  Open  vSwitch  do
68       not  address these cases uniformly. For VLAN and MPLS headers, only the
69       outermost header is accessible, so that inner headers may  be  accessed
70       only by ``popping’’ (removing) the outer header. (Open vSwitch supports
71       only a single VLAN header in any case.) For tunnels, e.g. GRE or VXLAN,
72       the  outer  header  and  inner  headers  are  treated as different data
73       fields.
74
75       Many network protocols are built in layers as a stack  of  concatenated
76       headers.  Each  header  typically  contains  a ``next type’’ field that
77       indicates the type of the protocol header that follows,  e.g.  Ethernet
78       contains  an Ethertype and IPv4 contains a IP protocol type. The excep‐
79       tional cases, where protocols are layered but an outer layer  does  not
80       indicate  the  protocol  type  for  the  inner  layer, or gives only an
81       ambiguous indication, are troublesome. An  MPLS  header,  for  example,
82       only  indicates whether another MPLS header or some other protocol fol‐
83       lows, and in the latter case the inner protocol must be known from  the
84       context.  In  these exceptional cases, OpenFlow and Open vSwitch cannot
85       provide insight into the inner protocol data fields without  additional
86       context,  and  thus  they  treat  all later data fields as inapplicable
87       until an OpenFlow action explicitly specifies what protocol follows. In
88       the  case  of  MPLS,  the OpenFlow ``pop MPLS’’ action that removes the
89       last MPLS header from a packet provides this context, as the  Ethertype
90       of the payload. See Layer 2.5: MPLS for more information.
91
92       OpenFlow  and  Open vSwitch support some fields other than data fields.
93       Metadata fields relate to the origin or treatment of a packet, but they
94       are not extracted from the packet data itself. One example is the phys‐
95       ical port on which a packet arrived at the switch. Register fields  act
96       like  variables: they give an OpenFlow switch space for temporary stor‐
97       age while processing a packet. Existing metadata  and  register  fields
98       have no prerequisites.
99
100       A  field’s  value  consists  of  an  integral number of bytes. For data
101       fields, sometimes those bytes are taken directly from the packet. Other
102       data  fields  are copied from a packet with padding (usually with zeros
103       and in the most significant positions). The remaining data  fields  are
104       transformed  in other ways as they are copied from the packets, to make
105       them more useful for matching.
106
107   Matching
108       The most important use of fields in OpenFlow is matching, to  determine
109       whether  particular field values agree with a set of constraints called
110       a match. A match consists of zero or  more  constraints  on  individual
111       fields,  all  of  which must be met to satisfy the match. (A match that
112       contains no constraints is always satisfied.) OpenFlow and Open vSwitch
113       support a number of forms of matching on individual fields:
114
115              Exact match, e.g. nw_src=10.1.2.3
116                     Only  a  particular  value  of  the field is matched; for
117                     example, only one particular  source  IP  address.  Exact
118                     matches  are  written  as field=value. The forms accepted
119                     for value depend on the field.
120
121                     All fields support exact matches.
122
123              Bitwise match, e.g. nw_src=10.1.0.0/255.255.0.0
124                     Specific bits in the field must  have  specified  values;
125                     for  example,  only  source  IP addresses in a particular
126                     subnet. Bitwise matches are written as  field=value/mask,
127                     where  value  and mask take one of the forms accepted for
128                     an exact match on field. Some fields accept  other  forms
129                     for       bitwise       matches;       for       example,
130                     nw_src=10.1.0.0/255.255.0.0   may   also    be    written
131                     nw_src=10.1.0.0/16.
132
133                     Most  OpenFlow switches do not allow every bitwise match‐
134                     ing on every field (and before OpenFlow 1.2, the protocol
135                     did  not  even  provide  for  the  possibility  for  most
136                     fields). Even switches that do allow bitwise matching  on
137                     a  given  field  may restrict the masks that are allowed,
138                     e.g. by allowing matches only on contiguous sets of  bits
139                     starting from the most significant bit, that is, ``CIDR’’
140                     masks [RFC 4632]. Open vSwitch does  not  allows  bitwise
141                     matching  on every field, but it allows arbitrary bitwise
142                     masks on any field that does  support  bitwise  matching.
143                     (Older  versions  had some restrictions, as documented in
144                     the descriptions of individual fields.)
145
146              Wildcard, e.g. ``any nw_src’’
147                     The value of the field  is  not  constrained.  Wildcarded
148                     fields  may be written as field=*, although it is unusual
149                     to mention them  at  all.  (When  specifying  a  wildcard
150                     explicitly  in  a  command  invocation,  be sure to using
151                     quoting to protect against shell expansion.)
152
153                     There is a tiny difference between  wildcarding  a  field
154                     and  not  specifying  any match on a field: wildcarding a
155                     field requires satisfying the field’s prerequisites.
156
157       Some types of matches on individual fields cannot be expressed directly
158       with OpenFlow and Open vSwitch. These can be expressed indirectly:
159
160              Set match, e.g. ``tcp_dst ∈ {80, 443, 8080}’’
161                     The value of a field is one of a specified set of values;
162                     for example, the TCP destination  port  is  80,  443,  or
163                     8080.
164
165                     For  matches  used  in flows (see Flows, below), multiple
166                     flows can simulate set matches.
167
168              Range match, e.g. ``1000 ≤ tcp_dst ≤ 1999’’
169                     The value of the field must lie within a numerical range,
170                     for example, TCP destination ports between 1000 and 1999.
171
172                     Range matches can be expressed as a collection of bitwise
173                     matches. For example, suppose that the goal is  to  match
174                     TCP source ports 1000 to 1999, inclusive. The binary rep‐
175                     resentations of 1000 and 1999 are:
176
177                     01111101000
178                     11111001111
179
180
181                     The following series of bitwise matches will  match  1000
182                     and 1999 and all the values in between:
183
184                     01111101xxx
185                     0111111xxxx
186                     10xxxxxxxxx
187                     110xxxxxxxx
188                     1110xxxxxxx
189                     11110xxxxxx
190                     1111100xxxx
191
192
193                     which can be written as the following matches:
194
195                     tcp,tp_src=0x03e8/0xfff8
196                     tcp,tp_src=0x03f0/0xfff0
197                     tcp,tp_src=0x0400/0xfe00
198                     tcp,tp_src=0x0600/0xff00
199                     tcp,tp_src=0x0700/0xff80
200                     tcp,tp_src=0x0780/0xffc0
201                     tcp,tp_src=0x07c0/0xfff0
202
203
204              Inequality match, e.g. ``tcp_dst ≠ 80’’
205                     The  value  of  the field differs from a specified value,
206                     for example, all TCP destination ports except 80.
207
208                     An inequality match on an n-bit field can be expressed as
209                     a  disjunction  of  n  1-bit  matches.  For  example, the
210                     inequality match ``vlan_pcp ≠ 5’’  can  be  expressed  as
211                     ``vlan_pcp  =  0/4 or vlan_pcp = 2/2 or vlan_pcp = 0/1.’’
212                     For matches used in flows (see Flows,  below),  sometimes
213                     one  can  more  compactly express inequality as a higher-
214                     priority flow that matches the  exceptional  case  paired
215                     with a lower-priority flow that matches the general case.
216
217                     Alternatively,  an inequality match may be converted to a
218                     pair of range matches, e.g. tcp_src ≠ 80 may be expressed
219                     as ``0 ≤ tcp_src < 80 or 80 < tcp_src ≤ 65535’’, and then
220                     each range match may in turn be converted  to  a  bitwise
221                     match.
222
223              Conjunctive  match, e.g. ``tcp_src ∈ {80, 443, 8080} and tcp_dst
224              ∈ {80, 443, 8080}’’
225                     As an OpenFlow extension, Open vSwitch supports  matching
226                     on conditions on conjunctions of the previously mentioned
227                     forms of matching. See the documentation for conj_id  for
228                     more information.
229
230       All  of  these supported forms of matching are special cases of bitwise
231       matching. In some cases this influences the  design  of  field  values.
232       ip_frag  is  the  most prominent example: it is designed to make all of
233       the practically useful checks for IP fragmentation possible as a single
234       bitwise match.
235
236     Shorthands
237
238       Some  matches are very commonly used, so Open vSwitch accepts shorthand
239       notations. In some cases, Open vSwitch also  uses  shorthand  notations
240       when  it  displays  matches. The following shorthands are defined, with
241       their long forms shown on the right side:
242
243              eth    packet_type=(0,0) (Open vSwitch 2.8 and later)
244
245              ip     eth_type=0x0800
246
247              ipv6   eth_type=0x86dd
248
249              icmp   eth_type=0x0800,ip_proto=1
250
251              icmp6  eth_type=0x86dd,ip_proto=58
252
253              tcp    eth_type=0x0800,ip_proto=6
254
255              tcp6   eth_type=0x86dd,ip_proto=6
256
257              udp    eth_type=0x0800,ip_proto=17
258
259              udp6   eth_type=0x86dd,ip_proto=17
260
261              sctp   eth_type=0x0800,ip_proto=132
262
263              sctp6  eth_type=0x86dd,ip_proto=132
264
265              arp    eth_type=0x0806
266
267              rarp   eth_type=0x8035
268
269              mpls   eth_type=0x8847
270
271              mplsm  eth_type=0x8848
272
273   Evolution of OpenFlow Fields
274       The discussion so far applies to all OpenFlow  and  Open  vSwitch  ver‐
275       sions.  This section starts to draw in specific information by explain‐
276       ing, in broad terms, the treatment of fields and matches in each  Open‐
277       Flow version.
278
279     OpenFlow 1.0
280
281       OpenFlow  1.0  defined  the  OpenFlow  protocol  format of a match as a
282       fixed-length data structure that could match on the following fields:
283
284              ·      Ingress port.
285
286              ·      Ethernet source and destination MAC.
287
288              ·      Ethertype (with a special value to match frames that lack
289                     an Ethertype).
290
291              ·      VLAN ID and priority.
292
293              ·      IPv4 source, destination, protocol, and DSCP.
294
295              ·      TCP source and destination port.
296
297              ·      UDP source and destination port.
298
299              ·      ICMPv4 type and code.
300
301              ·      ARP IPv4 addresses (SPA and TPA) and opcode.
302
303       Each supported field corresponded to some member of the data structure.
304       Some members represented multiple fields, in the case of the TCP,  UDP,
305       ICMPv4,  and ARP fields whose presence is mutually exclusive. This also
306       meant that some members were poor fits for their fields: only the low 8
307       bits of the 16-bit ARP opcode could be represented, and the ICMPv4 type
308       and code were padded with 8 bits of zeros to fit in the 16-bit  members
309       primarily  meant  for  TCP  and  UDP ports. An additional bitmap member
310       indicated, for each member, whether its field should be an ``exact’’ or
311       ``wildcarded’’  match  (see Matching), with additional support for CIDR
312       prefix matching on the IPv4 source and destination fields.
313
314       Simplicity was recognized early on as the main virtue of this approach.
315       Obviously,  any fixed-length data structure cannot support matching new
316       protocols that do not fit. There was no room, for example, for matching
317       IPv6 fields, which was not a priority at the time. Lack of room to sup‐
318       port matching the Ethernet addresses inside ARP packets actually caused
319       more  of  a  design problem later, leading to an Open vSwitch extension
320       action specialized for dropping ``spoofed’’ ARP packets  in  which  the
321       frame  and  ARP Ethernet source addressed differed. (This extension was
322       never standardized. Open vSwitch dropped support for it a few  releases
323       after it added support for full ARP matching.)
324
325       The  design  of the OpenFlow fixed-length matches also illustrates com‐
326       promises, in both directions, between the strengths and  weaknesses  of
327       software  and  hardware that have always influenced the design of Open‐
328       Flow. Support for matching ARP fields that do fit in the data structure
329       was  only  added  late  in the design process (and remained optional in
330       OpenFlow 1.0), for example, because common switch ASICs did not support
331       matching these fields.
332
333       The compromises in favor of software occurred for more complicated rea‐
334       sons. The OpenFlow designers did not know how to implement matching  in
335       software  that  was  fast, dynamic, and general. (A way was later found
336       [Srinivasan].) Thus, the designers sought to support  dynamic,  general
337       matching  that  would be fast in realistic special cases, in particular
338       when all of the matches were microflows, that is, matches that  specify
339       every  field  present  in  a packet, because such matches can be imple‐
340       mented as a single hash table lookup. Contemporary  research  supported
341       the  feasibility of this approach: the number of microflows in a campus
342       network had been measured to peak  at  about  10,000  [Casado,  section
343       3.2]. (Calculations show that this can only be true in a lightly loaded
344       network [Pepelnjak].)
345
346       As a result, OpenFlow 1.0 required switches to treat microflow  matches
347       as  the  highest  possible priority. This let software switches perform
348       the microflow hash table lookup first.  Only  on  failure  to  match  a
349       microflow did the switch need to fall back to checking the more general
350       and presumed slower matches. Also, the OpenFlow 1.0 flow match was min‐
351       imally  flexible,  with no support for general bitwise matching, partly
352       on the basis that this seemed more likely amenable to relatively  effi‐
353       cient  software  implementation.  (CIDR  masking for IPv4 addresses was
354       added relatively late in the OpenFlow 1.0 design process.)
355
356       Microflow matching was later discovered to aid some hardware  implemen‐
357       tations.  The  TCAM  chips used for matching in hardware do not support
358       priority in the same way as OpenFlow but instead tie priority to order‐
359       ing  [Pagiamtzis]. Thus, adding a new match with a priority between the
360       priorities of existing matches can require reordering an arbitrary num‐
361       ber  of  TCAM  entries.  On the other hand, when microflows are highest
362       priority, they can be managed  as  a  set-aside  portion  of  the  TCAM
363       entries.
364
365       The  emphasis  on  matching  microflows also led designers to carefully
366       consider the bandwidth requirements between switch and  controller:  to
367       maximize  the  number of microflow setups per second, one must minimize
368       the size of each flow’s description. This favored the fixed-length for‐
369       mat in use, because it expressed common TCP and UDP microflows in fewer
370       bytes than more flexible ``type-length-value’’  (TLV)  formats.  (Early
371       versions  of OpenFlow also avoided TLVs in general to head off protocol
372       fragmentation.)
373
374       Inapplicable Fields
375
376       OpenFlow 1.0 does not clearly specify how to treat inapplicable fields.
377       The  members  for  inapplicable  fields are always present in the match
378       data structure, as are the bits that indicate whether  the  fields  are
379       matched,  and  the  ``correct’’  member and bit values for inapplicable
380       fields is unclear. OpenFlow 1.0 implementations changed their  behavior
381       over time as priorities shifted. The early OpenFlow reference implemen‐
382       tation, motivated to make every flow a  microflow  to  enable  hashing,
383       treated  inapplicable  fields  as  exact  matches on a value of 0. Ini‐
384       tially, this behavior was implemented in the reference controller only.
385
386       Later, the reference switch was also  changed  to  actually  force  any
387       wildcarded  inapplicable  fields  into  exact  matches on 0. The latter
388       behavior sometimes caused problems, because the modified flow  was  the
389       one  reported back to the controller later when it queried the flow ta‐
390       ble, and the modifications sometimes meant that  the  controller  could
391       not  properly recognize the flow that it had added. In retrospect, per‐
392       haps this problem should have alerted the designers to a design  error,
393       but  the  ability to use a single hash table was held to be more impor‐
394       tant than almost every other consideration at the time.
395
396       When more flexible match formats were introduced much later, they  dis‐
397       allowed  any  mention  of  inapplicable fields as part of a match. This
398       raised the question of how to translate between this new format and the
399       OpenFlow 1.0 fixed format. It seemed somewhat inconsistent and backward
400       to treat fields as exact-match in one format and forbid  matching  them
401       in  the  other,  so instead the treatment of inapplicable fields in the
402       fixed-length format was changed from exact match on 0  to  wildcarding.
403       (A  better  classifier had by now eliminated software performance prob‐
404       lems with wildcards.)
405
406       The OpenFlow 1.0.1 errata (released only in 2012) added some additional
407       explanation  [OpenFlow 1.0.1, section 3.4], but it did not mandate spe‐
408       cific behavior because of variation among implementations.
409
410     OpenFlow 1.1
411
412       The  OpenFlow  1.1  protocol   match   format   was   designed   as   a
413       type/length/value  (TLV)  format  to  allow for future flexibility. The
414       specification standardized only a single type OFPMT_STANDARD (0) with a
415       fixed-size  payload,  described here. The additional fields and bitwise
416       masks in OpenFlow 1.1 cause this match structure to be  over  twice  as
417       large as in OpenFlow 1.0, 88 bytes versus 40.
418
419       OpenFlow 1.1 added support for the following fields:
420
421              ·      SCTP source and destination port.
422
423              ·      MPLS label and traffic control (TC) fields.
424
425              ·      One 64-bit register (named ``metadata’’).
426
427       OpenFlow  1.1 increased the width of the ingress port number field (and
428       all other port numbers in the protocol) from 16 bits to 32 bits.
429
430       OpenFlow 1.1 increased matching flexibility  by  introducing  arbitrary
431       bitwise  matching  on  Ethernet  and IPv4 address fields and on the new
432       ``metadata’’ register field. Switches were not required to support  all
433       possible masks [OpenFlow 1.1, section 4.3].
434
435       By  a strict reading of the specification, OpenFlow 1.1 removed support
436       for matching ICMPv4 type and code [OpenFlow 1.1,  section  A.2.3],  but
437       this  is  likely  an  editing  error because ICMP matching is described
438       elsewhere [OpenFlow 1.1, Table 3, Table 4, Figure 4]. Open vSwitch does
439       support ICMPv4 type and code matching with OpenFlow 1.1.
440
441       OpenFlow  1.1 avoided the pitfalls of inapplicable fields that OpenFlow
442       1.0 encountered, by requiring the switch to ignore the specified  field
443       values  [OpenFlow  1.1, section A.2.3]. It also implied that the switch
444       should ignore the bits that  indicate  whether  to  match  inapplicable
445       fields.
446
447       Physical Ingress Port
448
449       OpenFlow  1.1 introduced a new pseudo-field, the physical ingress port.
450       The physical ingress port is only a pseudo-field because it  cannot  be
451       used  for  matching.  It appears only one place in the protocol, in the
452       ``packet-in’’ message that passes a packet received at the switch to an
453       OpenFlow controller.
454
455       A  packet’s ingress port and physical ingress port are identical except
456       for packets processed by a switch feature such as bonding or  tunneling
457       that  makes  a packet appear to arrive on a ``virtual’’ port associated
458       with the bond or the tunnel. For such packets, the ingress port is  the
459       virtual  port and the physical ingress port is, naturally, the physical
460       port. Open vSwitch implements both bonding and tunneling, but its bond‐
461       ing implementation does not use virtual ports and its tunnels are typi‐
462       cally not on the same OpenFlow switch as their physical  ingress  ports
463       (which  need not be part of any switch), so the ingress port and physi‐
464       cal ingress port are always the same in Open vSwitch.
465
466     OpenFlow 1.2
467
468       OpenFlow 1.2 abandoned the fixed-length approach to matching. One  rea‐
469       son  was size, since adding support for IPv6 address matching (now seen
470       as important), with bitwise masks, would have added  64  bytes  to  the
471       match  length,  increasing it from 88 bytes in OpenFlow 1.1 to over 150
472       bytes. Extensibility had also become important  as  controller  writers
473       increasingly  wanted  support  for  new fields without having to change
474       messages throughout the OpenFlow protocol. The challenges of  carefully
475       defining  fixed-length  matches  to  avoid  problems  with inapplicable
476       fields had also become clear over time.
477
478       Therefore, OpenFlow 1.2 adopted a flow format using  a  flexible  type-
479       length-value  (TLV) representation, in which each TLV expresses a match
480       on one field. These TLVs were in turn encapsulated inside the outer TLV
481       wrapper  introduced  in  OpenFlow 1.1 with the new identifier OFPMT_OXM
482       (1). (This wrapper fulfilled  its  intended  purpose  of  reducing  the
483       amount  of churn in the protocol when changing match formats; some mes‐
484       sages that included matches remained unchanged from OpenFlow 1.1 to 1.2
485       and later versions.)
486
487       OpenFlow 1.2 added support for the following fields:
488
489              ·      ARP hardware addresses (SHA and THA).
490
491              ·      IPv4 ECN.
492
493              ·      IPv6  source and destination addresses, flow label, DSCP,
494                     ECN, and protocol.
495
496              ·      TCP, UDP, and SCTP port numbers when encapsulated  inside
497                     IPv6.
498
499              ·      ICMPv6 type and code.
500
501              ·      ICMPv6  Neighbor  Discovery target address and source and
502                     target Ethernet addresses.
503
504       The OpenFlow 1.2 format, called OXM (OpenFlow  Extensible  Match),  was
505       modeled  closely  on  an  extension  to OpenFlow 1.0 introduced in Open
506       vSwitch 1.1 called NXM (Nicira Extended Match). Each OXM or NXM TLV has
507       the following format:
508
509               type
510        <---------------->
511             16        7   1    8      length bytes
512       +------------+-----+--+------+ +------------+
513       |vendor/class|field|HM|length| |    body    |
514       +------------+-----+--+------+ +------------+
515
516
517       The most significant 16 bits of the NXM or OXM header, called vendor by
518       NXM and class by OXM, identify an organization  permitted  to  allocate
519       identifiers  for  fields.  NXM  allocates  only two vendors, 0x0000 for
520       fields supported by OpenFlow 1.0 and 0x0001 for fields  implemented  as
521       an Open vSwitch extension. OXM assigns classes as follows:
522
523              0x0000 (OFPXMC_NXM_0).
524              0x0001 (OFPXMC_NXM_1).
525                   Reserved for NXM compatibility.
526
527              0x0002 to 0x7fff
528                   Reserved  for  allocation  to  ONF  members,  but  none yet
529                   assigned.
530
531              0x8000 (OFPXMC_OPENFLOW_BASIC)
532                   Used for most standard OpenFlow fields.
533
534              0x8001 (OFPXMC_PACKET_REGS)
535                   Used for packet register fields in OpenFlow 1.5 and later.
536
537              0x8002 to 0xfffe
538                   Reserved for the OpenFlow specification.
539
540              0xffff (OFPXMC_EXPERIMENTER)
541                   Experimental use.
542
543       When class is 0xffff, the OXM header is extended to 64  bits  by  using
544       the  first 32 bits of the body as an experimenter field whose most sig‐
545       nificant byte is zero and whose remaining bytes are an Organizationally
546       Unique  Identifier  (OUI)  assigned  by  the  IEEE [IEEE OUI], as shown
547       below.
548
549            type                 experimenter
550        <---------->             <---------->
551          16     7   1    8        8     24     (length - 4) bytes
552       +------+-----+--+------+ +------+-----+ +------------------+
553       |class |field|HM|length| | zero | OUI | |       body       |
554       +------+-----+--+------+ +------+-----+ +------------------+
555        0xffff                    0x00
556
557
558       OpenFlow says that support for experimenter fields  is  optional.  Open
559       vSwitch  2.4  and  later  does support them, so that it can support the
560       following experimenter classes:
561
562              0x4f4e4600 (ONFOXM_ET)
563                     Used by official Open Networking Foundation extensions in
564                     OpenFlow  1.3  and  later.  e.g.  [TCP  Flags Match Field
565                     Extension].
566
567              0x005ad650 (NXOXM_NSH)
568                     Used by Open vSwitch for NSH extensions, in  the  absence
569                     of  an official ONF-assigned class. (This OUI is randomly
570                     generated.)
571
572       Taken as a unit, class  (or  vendor),  field,  and  experimenter  (when
573       present) uniquely identify a particular field.
574
575       When  hasmask (abbreviated HM above) is 0, the OXM is an exact match on
576       an entire field. In this case, the  body  (excluding  the  experimenter
577       field, if present) is a single value to be matched.
578
579       When  hasmask is 1, the OXM is a bitwise match. The body (excluding the
580       experimenter field) consists of a value to match, followed by the  bit‐
581       wise  mask to apply. A 1-bit in the mask indicates that the correspond‐
582       ing bit in the value should be matched and a 0-bit that  it  should  be
583       ignored.  For  example, for an IP address field, a value of 192.168.0.0
584       followed by  a  mask  of  255.255.0.0  would  match  addresses  in  the
585       196.168.0.0/16 subnet.
586
587              ·      Some  fields  might  not support masking at all, and some
588                     fields that do support masking might restrict it to  cer‐
589                     tain  patterns.  For example, fields that have IP address
590                     values might be restricted to CIDR  masks.  The  descrip‐
591                     tions of individual fields note these restrictions.
592
593              ·      An  OXM  TLV  with a mask that is all zeros is not useful
594                     (although it is not forbidden), because  it  is  has  the
595                     same effect as omitting the TLV entirely.
596
597              ·      It  is not meaningful to pair a 0-bit in an OXM mask with
598                     a 1-bit in its value, and Open vSwitch  rejects  such  an
599                     OXM  with  the error OFPBMC_BAD_WILDCARDS, as required by
600                     OpenFlow 1.3 and later.
601
602       The length identifies the number of bytes in the  body,  including  the
603       4-byte  experimenter header, if it is present. Each OXM TLV has a fixed
604       length; that is, given class, field,  experimenter  (if  present),  and
605       hasmask,  length  is  a  constant. The length is included explicitly to
606       allow software to minimally parse OXM TLVs of unknown types.
607
608       OXM TLVs must be ordered so that a field’s prerequisites are  satisfied
609       before  it  is parsed. For example, an OXM TLV that matches on the IPv4
610       source address field is only allowed following an OXM TLV that  matches
611       on  the  Ethertype  for IPv4. Similarly, an OXM TLV that matches on the
612       TCP source port must follow a TLV that matches an Ethertype of IPv4  or
613       IPv6  and  one  that matches an IP protocol of TCP (in that order). The
614       order of OXM TLVs is not otherwise restricted; no canonical ordering is
615       defined.
616
617       A given field may be matched only once in a series of OXM TLVs.
618
619     OpenFlow 1.3
620
621       OpenFlow  1.3 showed OXM to be largely successful, by adding new fields
622       without making any changes to how flow  matches  otherwise  worked.  It
623       added OXMs for the following fields supported by Open vSwitch:
624
625              ·      Tunnel  ID  for ports associated with e.g. VXLAN or keyed
626                     GRE.
627
628              ·      MPLS ``bottom of stack’’ (BOS) bit.
629
630       OpenFlow 1.3 also added OXMs for the following  fields  not  documented
631       here and not yet implemented by Open vSwitch:
632
633              ·      IPv6 extension header handling.
634
635              ·      PBB I-SID.
636
637     OpenFlow 1.4
638
639       OpenFlow  1.4  added  OXMs for the following fields not documented here
640       and not yet implemented by Open vSwitch:
641
642              ·      PBB UCA.
643
644     OpenFlow 1.5
645
646       OpenFlow 1.5 added OXMs for the  following  fields  supported  by  Open
647       vSwitch:
648
649              ·      Packet type.
650
651              ·      TCP flags.
652
653              ·      Packet registers.
654
655              ·      The output port in the OpenFlow action set.
656

FIELDS REFERENCE

658       The  following sections document the fields that Open vSwitch supports.
659       Each section provides introductory  material  on  a  group  of  related
660       fields,  followed  by information on each individual field. In addition
661       to field-specific information, each field  begins  with  a  table  with
662       entries for the following important properties:
663
664              Name   The  field’s  name,  used  for parsing and formatting the
665                     field, e.g. in ovs-ofctl commands.  For  historical  rea‐
666                     sons,  some  fields  have  an  additional  name  that  is
667                     accepted as an alternative in parsing.  This  name,  when
668                     there  is  one,  is  listed as well, e.g. ``tun (aka tun‐
669                     nel_id).’’
670
671              Width  The field’s width, always a  multiple  of  8  bits.  Some
672                     fields don’t use all of the bits, so this may be accompa‐
673                     nied by an explanation. For example, OpenFlow embeds  the
674                     2-bit  IP  ECN field as as the low bits in an 8-bit byte,
675                     and so its width is  expressed  as  ``8  bits  (only  the
676                     least-significant 2 bits may be nonzero).’’
677
678              Format How  a  value  for  the  field is formatted or parsed by,
679                     e.g., ovs-ofctl. Some possibilities are generic:
680
681                     decimal
682                            Formats as a decimal  number.  On  input,  accepts
683                            decimal numbers or hexadecimal numbers prefixed by
684                            0x.
685
686                     hexadecimal
687                            Formats as a hexadecimal number prefixed by 0x. On
688                            input, accepts decimal numbers or hexadecimal num‐
689                            bers prefixed by 0x. (The default for  parsing  is
690                            not  hexadecimal: only a 0x prefix causes input to
691                            be treated as hexadecimal.)
692
693                     Ethernet
694                            Formats and accepts the  common  Ethernet  address
695                            format xx:xx:xx:xx:xx:xx.
696
697                     IPv4   Formats   and   accepts   the  dotted-quad  format
698                            a.b.c.d. For bitwise matches, formats and  accepts
699                            address/length   CIDR   notation  in  addition  to
700                            address/mask.
701
702                     IPv6   Formats and accepts the common IPv6  address  for‐
703                            mats, plus CIDR notation for bitwise matches.
704
705                     OpenFlow 1.0 port
706                            Accepts 16-bit port numbers in decimal, plus Open‐
707                            Flow  well-known  port  names  (e.g.  IN_PORT)  in
708                            uppercase or lowercase.
709
710                     OpenFlow 1.1+ port
711                            Same  syntax  as OpenFlow 1.0 ports but for 32-bit
712                            OpenFlow 1.1+ port number fields.
713
714                     Other, field-specific formats are  explained  along  with
715                     their fields.
716
717              Masking
718                     For  most  fields, this says ``arbitrary bitwise masks,’’
719                     meaning that a flow may match any combination of bits  in
720                     the  field. Some fields instead say ``exact match only,’’
721                     which means that a flow that matches on this  field  must
722                     match  on  the  whole field instead of just certain bits.
723                     Either way, this reports masking support for  the  latest
724                     version of Open vSwitch using OXM or NXM (that is, either
725                     OpenFlow 1.2+ or  OpenFlow  1.0  plus  Open  vSwitch  NXM
726                     extensions).  In  particular,  OpenFlow 1.0 (without NXM)
727                     and 1.1 don’t always support masking even if Open vSwitch
728                     itself  does;  refer to the OpenFlow 1.0 and OpenFlow 1.1
729                     rows to learn about masking with these protocol versions.
730
731              Prerequisites
732                     Requirements that must be met to match on this field. For
733                     example,  ip_src has IPv4 as a prerequisite, meaning that
734                     a match must include eth_type=0x0800 to match on the IPv4
735                     source  address.  The following prerequisites, with their
736                     requirements, are currently in use:
737
738                     none   (no requirements)
739
740                     VLAN VID
741                            vlan_tci=0x1000/0x1000  (i.e.  a  VLAN  header  is
742                            present)
743
744                     ARP    eth_type=0x0806 (ARP) or eth_type=0x8035 (RARP)
745
746                     IPv4   eth_type=0x0800
747
748                     IPv6   eth_type=0x86dd
749
750                     IPv4/IPv6
751                            IPv4 or IPv6
752
753                     MPLS   eth_type=0x8847 or eth_type=0x8848
754
755                     TCP    IPv4/IPv6 and ip_proto=6
756
757                     UDP    IPv4/IPv6 and ip_proto=17
758
759                     SCTP   IPv4/IPv6 and ip_proto=132
760
761                     ICMPv4 IPv4 and ip_proto=1
762
763                     ICMPv6 IPv6 and ip_proto=58
764
765                     ND solicit
766                            ICMPv6 and icmp_type=135 and icmp_code=0
767
768                     ND advert
769                            ICMPv6 and icmp_type=136 and icmp_code=0
770
771                     ND     ND solicit or ND advert
772
773                     The  TCP,  UDP, and SCTP prerequisites also have the spe‐
774                     cial requirement that nw_frag is not being used to select
775                     ``later fragments.’’ This is because only the first frag‐
776                     ment of a fragmented IPv4 or IPv6 datagram  contains  the
777                     TCP or UDP header.
778
779              Access Most  fields  are ``read/write,’’ which means that common
780                     OpenFlow actions like set_field can modify  them.  Fields
781                     that  are  ``read-only’’ cannot be modified in these gen‐
782                     eral-purpose ways, although there may be other ways  that
783                     actions can modify them.
784
785              OpenFlow 1.0
786              OpenFlow 1.1
787                   These rows report the level of support that OpenFlow 1.0 or
788                   OpenFlow 1.1, respectively, has for a field.  For  OpenFlow
789                   1.0,  supported  fields are reported as either ``yes (exact
790                   match only)’’ for fields that do not  support  any  bitwise
791                   masking  or  ``yes (CIDR match only)’’ for fields that sup‐
792                   port CIDR masking. OpenFlow  1.1  supported  fields  report
793                   either  ``yes  (exact  match  only)’’ or simply ``yes’’ for
794                   fields that do support arbitrary masks. These OpenFlow ver‐
795                   sions supported a fixed collection of fields that cannot be
796                   extended, so many more fields are reported  as  ``not  sup‐
797                   ported.’’
798
799              OXM
800              NXM  These  rows  report the OXM and NXM code points that corre‐
801                   spond to a given field. Either or both may be ``none.’’
802
803                   A field that has only an OXM code point is usually one that
804                   was  standardized  before  it  was added to Open vSwitch. A
805                   field that has only an NXM code point is usually  one  that
806                   is  not yet standardized. When a field has both OXM and NXM
807                   code points, it usually indicates that it was introduced as
808                   an  Open  vSwitch  extension under the NXM code point, then
809                   later standardized under the OXM code point.  A  field  can
810                   have more than one OXM code point if it was standardized in
811                   OpenFlow 1.4 or later and  additionally  introduced  as  an
812                   official  ONF extension for OpenFlow 1.3. (A field that has
813                   neither OXM nor NXM code point  is  typically  an  obsolete
814                   field  that  is  supported  in some other form using OXM or
815                   NXM.)
816
817                   Each code point in these rows  is  described  in  the  form
818                   ``NAME  (number)  since OpenFlow spec and Open vSwitch ver‐
819                   sion,’’ e.g. ``OXM_OF_ETH_TYPE (5) since OpenFlow  1.2  and
820                   Open vSwitch 1.7.’’ First, NAME, which specifies a name for
821                   the code point, starts with  a  prefix  that  designates  a
822                   class  and,  in some cases, a vendor, as listed in the fol‐
823                   lowing table:
824
825                   Prefix           Vendor       Class
826                   ───────────────  ───────────  ───────
827                   NXM_OF           (none)       0x0000
828                   NXM_NX           (none)       0x0001
829                   ERICOXM_OF       (none)       0x1000
830                   OXM_OF           (none)       0x8000
831                   OXM_OF_PKT_REG   (none)       0x8001
832                   NXOXM_ET         0x00002320   0xffff
833                   NXOXM_NSH        0x005ad650   0xffff
834                   ONFOXM_ET        0x4f4e4600   0xffff
835
836                   For more information on OXM/NXM classes and vendors,  refer
837                   back  to  OpenFlow  1.2 under Evolution of OpenFlow Fields.
838                   The number is the field number within the class and vendor.
839                   The OpenFlow spec is the version of OpenFlow that standard‐
840                   ized the code point. It is  omitted  for  NXM  code  points
841                   because they are nonstandard. The version is the version of
842                   Open vSwitch that first supported the code point.
843

CONJUNCTIVE MATCH FIELDS

845   Summary:
846       Name      Bytes   Mask   RW?   Prereqs   NXM/OXM Support
847       ────────  ──────  ─────  ────  ────────  ────────────────
848       conj_id   4       no     no    none      OVS 2.4+
849
850       An individual OpenFlow flow can match only  a  single  value  for  each
851       field.  However, situations often arise where one wants to match one of
852       a set of values within a field or fields. For matching a  single  field
853       against  a  set,  it  is  straightforward and efficient to add multiple
854       flows to the flow table, one for each value in the  set.  For  example,
855       one  might  use  the  following  flows  to  send packets with IP source
856       address a, b, c, or d to the OpenFlow controller:
857
858             ip,ip_src=a actions=controller
859             ip,ip_src=b actions=controller
860             ip,ip_src=c actions=controller
861             ip,ip_src=d actions=controller
862
863
864       Similarly, these flows send packets with IP destination address  e,  f,
865       g, or h to the OpenFlow controller:
866
867             ip,ip_dst=e actions=controller
868             ip,ip_dst=f actions=controller
869             ip,ip_dst=g actions=controller
870             ip,ip_dst=h actions=controller
871
872
873       Installing  all of the above flows in a single flow table yields a dis‐
874       junctive effect: a packet  is  sent  to  the  controller  if  ip_src  
875       {a,b,c,d}  or  ip_dst  ∈ {e,f,g,h} (or both). (Pedantically, if both of
876       the above sets of flows are present in the flow table, they should have
877       different  priorities, because OpenFlow says that the results are unde‐
878       fined when two flows  with  same  priority  can  both  match  a  single
879       packet.)
880
881       Suppose, on the other hand, one wishes to match conjunctively, that is,
882       to send a packet to the controller only if both ip_src ∈ {a,b,c,d}  and
883       ip_dst ∈ {e,f,g,h}. This requires 4 × 4 = 16 flows, one for each possi‐
884       ble pairing of ip_src and ip_dst. That  is  acceptable  for  our  small
885       example,  but  it  does not gracefully extend to larger sets or greater
886       numbers of dimensions.
887
888       The conjunction action is a solution for conjunctive  matches  that  is
889       built into Open vSwitch. A conjunction action ties groups of individual
890       OpenFlow flows into higher-level ``conjunctive flows’’. Each group cor‐
891       responds  to  one dimension, and each flow within the group matches one
892       possible value for the dimension. A packet that matches one  flow  from
893       each group matches the conjunctive flow.
894
895       To  implement  a conjunctive flow with conjunction, assign the conjunc‐
896       tive flow a 32-bit id, which must be unique within an  OpenFlow  table.
897       Assign  each  of  the n ≥ 2 dimensions a unique number from 1 to n; the
898       ordering is unimportant. Add one flow to the OpenFlow  flow  table  for
899       each  possible value of each dimension with conjunction(id, k/n) as the
900       flow’s actions, where k is the number assigned to the flow’s dimension.
901       Together,  these  flows specify the conjunctive flow’s match condition.
902       When the conjunctive match condition is met, Open vSwitch looks up  one
903       more  flow  that  specifies the conjunctive flow’s actions and receives
904       its statistics. This flow is found by setting conj_id to the  specified
905       id and then again searching the flow table.
906
907       The  following  flows provide an example. Whenever the IP source is one
908       of the values in the flows that match on the IP source (dimension 1  of
909       2), and the IP destination is one of the values in the flows that match
910       on IP destination (dimension 2 of 2), Open vSwitch searches for a  flow
911       that  matches  conj_id  against  the conjunction ID (1234), finding the
912       first flow listed below.
913
914             conj_id=1234 actions=controller
915             ip,ip_src=10.0.0.1 actions=conjunction(1234, 1/2)
916             ip,ip_src=10.0.0.4 actions=conjunction(1234, 1/2)
917             ip,ip_src=10.0.0.6 actions=conjunction(1234, 1/2)
918             ip,ip_src=10.0.0.7 actions=conjunction(1234, 1/2)
919             ip,ip_dst=10.0.0.2 actions=conjunction(1234, 2/2)
920             ip,ip_dst=10.0.0.5 actions=conjunction(1234, 2/2)
921             ip,ip_dst=10.0.0.7 actions=conjunction(1234, 2/2)
922             ip,ip_dst=10.0.0.8 actions=conjunction(1234, 2/2)
923
924
925       Many subtleties exist:
926
927              ·      In the example above, every flow in  a  single  dimension
928                     has the same form, that is, dimension 1 matches on ip_src
929                     and dimension 2 on ip_dst, but this is not a requirement.
930                     Different flows within a dimension may match on different
931                     bits within a field (e.g. IP network prefixes of  differ‐
932                     ent  lengths, or TCP/UDP port ranges as bitwise matches),
933                     or even on entirely different fields (e.g. to match pack‐
934                     ets for TCP source port 80 or TCP destination port 80).
935
936              ·      The  flows  within  a  dimension  can  vary their matches
937                     across more than one field, e.g. to match  only  specific
938                     pairs  of  IP source and destination addresses or L4 port
939                     numbers.
940
941              ·      A flow may have multiple conjunction actions,  with  dif‐
942                     ferent id values. This is useful for multiple conjunctive
943                     flows with overlapping  sets.  If  one  conjunctive  flow
944                     matches  packets  with  both  ip_src ∈ {a,b} and ip_dst 
945                     {d,e} and a second  conjunctive  flow  matches  ip_src  
946                     {b,c} and ip_dst ∈ {f,g}, for example, then the flow that
947                     matches ip_src=b would have two conjunction actions,  one
948                     for  each  conjunctive  flow.  The  order  of conjunction
949                     actions within a list of actions is not significant.
950
951              ·      A flow with conjunction actions  may  also  include  note
952                     actions  for  annotations,  but  not  any  other  kind of
953                     actions. (They would not be  useful  because  they  would
954                     never be executed.)
955
956              ·      All  of the flows that constitute a conjunctive flow with
957                     a given id must have the same priority. (Flows  with  the
958                     same id but different priorities are currently treated as
959                     different conjunctive flows, that is, currently id values
960                     need  only  be unique within an OpenFlow table at a given
961                     priority. This behavior isn’t guaranteed to stay the same
962                     in  later releases, so please use id values unique within
963                     an OpenFlow table.)
964
965              ·      Conjunctive flows must not overlap with each other, at  a
966                     given priority, that is, any given packet must be able to
967                     match at most one conjunctive flow at a  given  priority.
968                     Overlapping   conjunctive   flows   yield   unpredictable
969                     results.
970
971              ·      Following a conjunctive flow match, the  search  for  the
972                     flow  with conj_id=id is done in the same general-purpose
973                     way as other flow table searches, so one  can  use  flows
974                     with  conj_id=id  to act differently depending on circum‐
975                     stances. (One  exception  is  that  the  search  for  the
976                     conj_id=id  flow  itself  ignores  conjunctive  flows, to
977                     avoid recursion.) If the search  with  conj_id=id  fails,
978                     Open  vSwitch  acts  as  if  the conjunctive flow had not
979                     matched at all, and continues searching  the  flow  table
980                     for other matching flows.
981
982              ·      OpenFlow  prerequisite  checking occurs for the flow with
983                     conj_id=id in the same way as any other flow, e.g. in  an
984                     OpenFlow  1.1+  context, putting a mod_nw_src action into
985                     the example above would require adding an ip match,  like
986                     this:
987
988                               conj_id=1234,ip actions=mod_nw_src:1.2.3.4,controller
989
990
991              ·      OpenFlow  prerequisite checking also occurs for the indi‐
992                     vidual flows that comprise a  conjunctive  match  in  the
993                     same way as any other flow.
994
995              ·      The  flows that constitute a conjunctive flow do not have
996                     useful statistics. They are never updated  with  byte  or
997                     packet  counts,  and  so on. (For such a flow, therefore,
998                     the idle and hard timeouts work much the same way.)
999
1000              ·      Sometimes there is a choice of which flows include a par‐
1001                     ticular  match.  For  example,  suppose  that we added an
1002                     extra constraint to our example, to  match  on  ip_src  
1003                     {a,b,c,d} and ip_dst ∈ {e,f,g,h} and tcp_dst = i. One way
1004                     to implement this is to add the  new  constraint  to  the
1005                     conj_id flow, like this:
1006
1007                               conj_id=1234,tcp,tcp_dst=i actions=mod_nw_src:1.2.3.4,controller
1008
1009
1010                     but  this  is  not recommended because of the cost of the
1011                     extra flow table lookup. Instead, add the  constraint  to
1012                     the  individual flows, either in one of the dimensions or
1013                     (slightly better) all of them.
1014
1015              ·      A conjunctive match must have n ≥ 2 dimensions (otherwise
1016                     a  conjunctive  match  is  not  necessary).  Open vSwitch
1017                     enforces this.
1018
1019              ·      Each dimension within a conjunctive match should ordinar‐
1020                     ily  have  more  than  one  flow.  Open  vSwitch does not
1021                     enforce this.
1022
1023       Conjunction ID Field
1024
1025       Name:            conj_id
1026       Width:           32 bits
1027       Format:          decimal
1028       Masking:         not maskable
1029       Prerequisites:   none
1030       Access:          read-only
1031       OpenFlow 1.0:    not supported
1032       OpenFlow 1.1:    not supported
1033       OXM:             none
1034       NXM:             NXM_NX_CONJ_ID (37) since Open vSwitch 2.4
1035
1036       Used for conjunctive matching. See above for more information.
1037

TUNNEL FIELDS

1039   Summary:
1040       Name                   Bytes             Mask   RW?   Prereqs   NXM/OXM Support
1041       ─────────────────────  ────────────────  ─────  ────  ────────  ─────────────────────
1042       tun_id aka tunnel_id   8                 yes    yes   none      OF 1.3+ and OVS 1.1+
1043       tun_src                4                 yes    yes   none      OVS 2.0+
1044       tun_dst                4                 yes    yes   none      OVS 2.0+
1045       tun_ipv6_src           16                yes    yes   none      OVS 2.5+
1046       tun_ipv6_dst           16                yes    yes   none      OVS 2.5+
1047       tun_gbp_id             2                 yes    yes   none      OVS 2.4+
1048       tun_gbp_flags          1                 yes    yes   none      OVS 2.4+
1049       tun_erspan_ver         1 (low 4 bits)    yes    yes   none      OVS 2.10+
1050
1051       tun_erspan_idx         4 (low 20 bits)   yes    yes   none      OVS 2.10+
1052       tun_erspan_dir         1 (low 1 bits)    yes    yes   none      OVS 2.10+
1053       tun_erspan_hwid        1 (low 6 bits)    yes    yes   none      OVS 2.10+
1054       tun_metadata0          124               yes    yes   none      OVS 2.5+
1055       tun_metadata1          124               yes    yes   none      OVS 2.5+
1056       tun_metadata2          124               yes    yes   none      OVS 2.5+
1057       tun_metadata3          124               yes    yes   none      OVS 2.5+
1058       tun_metadata4          124               yes    yes   none      OVS 2.5+
1059       tun_metadata5          124               yes    yes   none      OVS 2.5+
1060       tun_metadata6          124               yes    yes   none      OVS 2.5+
1061       tun_metadata7          124               yes    yes   none      OVS 2.5+
1062       tun_metadata8          124               yes    yes   none      OVS 2.5+
1063       tun_metadata9          124               yes    yes   none      OVS 2.5+
1064
1065       tun_metadata10         124               yes    yes   none      OVS 2.5+
1066       tun_metadata11         124               yes    yes   none      OVS 2.5+
1067       tun_metadata12         124               yes    yes   none      OVS 2.5+
1068       tun_metadata13         124               yes    yes   none      OVS 2.5+
1069       tun_metadata14         124               yes    yes   none      OVS 2.5+
1070       tun_metadata15         124               yes    yes   none      OVS 2.5+
1071       tun_metadata16         124               yes    yes   none      OVS 2.5+
1072       tun_metadata17         124               yes    yes   none      OVS 2.5+
1073       tun_metadata18         124               yes    yes   none      OVS 2.5+
1074       tun_metadata19         124               yes    yes   none      OVS 2.5+
1075       tun_metadata20         124               yes    yes   none      OVS 2.5+
1076       tun_metadata21         124               yes    yes   none      OVS 2.5+
1077       tun_metadata22         124               yes    yes   none      OVS 2.5+
1078
1079       tun_metadata23         124               yes    yes   none      OVS 2.5+
1080       tun_metadata24         124               yes    yes   none      OVS 2.5+
1081       tun_metadata25         124               yes    yes   none      OVS 2.5+
1082       tun_metadata26         124               yes    yes   none      OVS 2.5+
1083       tun_metadata27         124               yes    yes   none      OVS 2.5+
1084       tun_metadata28         124               yes    yes   none      OVS 2.5+
1085       tun_metadata29         124               yes    yes   none      OVS 2.5+
1086       tun_metadata30         124               yes    yes   none      OVS 2.5+
1087       tun_metadata31         124               yes    yes   none      OVS 2.5+
1088       tun_metadata32         124               yes    yes   none      OVS 2.5+
1089       tun_metadata33         124               yes    yes   none      OVS 2.5+
1090       tun_metadata34         124               yes    yes   none      OVS 2.5+
1091       tun_metadata35         124               yes    yes   none      OVS 2.5+
1092
1093       tun_metadata36         124               yes    yes   none      OVS 2.5+
1094       tun_metadata37         124               yes    yes   none      OVS 2.5+
1095       tun_metadata38         124               yes    yes   none      OVS 2.5+
1096       tun_metadata39         124               yes    yes   none      OVS 2.5+
1097       tun_metadata40         124               yes    yes   none      OVS 2.5+
1098       tun_metadata41         124               yes    yes   none      OVS 2.5+
1099       tun_metadata42         124               yes    yes   none      OVS 2.5+
1100       tun_metadata43         124               yes    yes   none      OVS 2.5+
1101       tun_metadata44         124               yes    yes   none      OVS 2.5+
1102       tun_metadata45         124               yes    yes   none      OVS 2.5+
1103       tun_metadata46         124               yes    yes   none      OVS 2.5+
1104       tun_metadata47         124               yes    yes   none      OVS 2.5+
1105       tun_metadata48         124               yes    yes   none      OVS 2.5+
1106
1107       tun_metadata49         124               yes    yes   none      OVS 2.5+
1108       tun_metadata50         124               yes    yes   none      OVS 2.5+
1109       tun_metadata51         124               yes    yes   none      OVS 2.5+
1110       tun_metadata52         124               yes    yes   none      OVS 2.5+
1111       tun_metadata53         124               yes    yes   none      OVS 2.5+
1112       tun_metadata54         124               yes    yes   none      OVS 2.5+
1113       tun_metadata55         124               yes    yes   none      OVS 2.5+
1114       tun_metadata56         124               yes    yes   none      OVS 2.5+
1115       tun_metadata57         124               yes    yes   none      OVS 2.5+
1116       tun_metadata58         124               yes    yes   none      OVS 2.5+
1117       tun_metadata59         124               yes    yes   none      OVS 2.5+
1118       tun_metadata60         124               yes    yes   none      OVS 2.5+
1119       tun_metadata61         124               yes    yes   none      OVS 2.5+
1120
1121       tun_metadata62         124               yes    yes   none      OVS 2.5+
1122       tun_metadata63         124               yes    yes   none      OVS 2.5+
1123       tun_flags              2 (low 1 bits)    yes    yes   none      OVS 2.5+
1124
1125       The fields in this group relate to tunnels, which Open vSwitch supports
1126       in  several  forms  (GRE,  VXLAN,  and  so on). Most of these fields do
1127       appear in the wire format of a packet, so they  are  data  fields  from
1128       that  point  of view, but they are metadata from an OpenFlow flow table
1129       point of view because they do not appear in packets that are  forwarded
1130       to the controller or to ordinary (non-tunnel) output ports.
1131
1132       Open vSwitch supports a spectrum of usage models for mapping tunnels to
1133       OpenFlow ports:
1134
1135              ``Port-based’’ tunnels
1136                     In this model, an OpenFlow port represents one tunnel: it
1137                     matches  a  particular type of tunnel traffic between two
1138                     IP endpoints, with a particular tunnel key (if  keys  are
1139                     in  use).  In this situation, in_port suffices to distin‐
1140                     guish one tunnel  from  another,  so  the  tunnel  header
1141                     fields  have  little  importance for OpenFlow processing.
1142                     (They are still populated and may be used if it is conve‐
1143                     nient.)  The tunnel header fields play no role in sending
1144                     packets out such an OpenFlow port,  either,  because  the
1145                     OpenFlow port itself fully specifies the tunnel headers.
1146
1147                     The  following  Open  vSwitch  commands  create  a bridge
1148                     br-int, add port tap0 to the bridge as OpenFlow  port  1,
1149                     establish  a port-based GRE tunnel between the local host
1150                     and remote IP 192.168.1.1 using GRE key 5001 as  OpenFlow
1151                     port  2, and arranges to forward all traffic from tap0 to
1152                     the tunnel and vice versa:
1153
1154                     ovs-vsctl add-br br-int
1155                     ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1156                     ovs-vsctl add-port br-int gre0 -- \
1157                         set interface gre0 ofport_request=2 type=gre \
1158                                            options:remote_ip=192.168.1.1 options:key=5001
1159                     ovs-ofctl add-flow br-int in_port=1,actions=2
1160                     ovs-ofctl add-flow br-int in_port=2,actions=1
1161
1162
1163              ``Flow-based’’ tunnels
1164                     In this model, one OpenFlow port represents all  possible
1165                     tunnels  of  a given type with an endpoint on the current
1166                     host, for example, all GRE tunnels.  In  this  situation,
1167                     in_port  only  indicates that traffic was received on the
1168                     particular kind of  tunnel.  This  is  where  the  tunnel
1169                     header fields are most important: they allow the OpenFlow
1170                     tables to discriminate among tunnels based  on  their  IP
1171                     endpoints  or  keys.  Tunnel header fields also determine
1172                     the IP endpoints and keys of packets sent out such a tun‐
1173                     nel port.
1174
1175                     The  following  Open  vSwitch  commands  create  a bridge
1176                     br-int, add port tap0 to the bridge as OpenFlow  port  1,
1177                     establish a flow-based GRE tunnel port 3, and arranges to
1178                     forward all traffic from tap0 to  remote  IP  192.168.1.1
1179                     over a GRE tunnel with key 5001 and vice versa:
1180
1181                     ovs-vsctl add-br br-int
1182                     ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1
1183                     ovs-vsctl add-port br-int allgre -- \
1184                         set interface allgre ofport_request=3 type=gre \
1185                                              options:remote_ip=flow options:key=flow
1186                     ovs-ofctl add-flow br-int \
1187                         ’in_port=1 actions=set_tunnel:5001,set_field:192.168.1.1->tun_dst,3’
1188                     ovs-ofctl add-flow br-int ’in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1’
1189
1190
1191              Mixed models.
1192                     One  may define both flow-based and port-based tunnels at
1193                     the same time. For example, it is valid and possibly use‐
1194                     ful  to  create and configure both gre0 and allgre tunnel
1195                     ports described above.
1196
1197                     Traffic is attributed on ingress  to  the  most  specific
1198                     matching  tunnel. For example, gre0 is more specific than
1199                     allgre. Therefore, if both exist, then gre0 will  be  the
1200                     ingress   port   for   any   GRE  traffic  received  from
1201                     192.168.1.1 with key 5001.
1202
1203                     On egress, traffic may be  directed  to  any  appropriate
1204                     tunnel  port.  If  both gre0 and allgre are configured as
1205                     already  described,  then  the  actions  2  and  set_tun‐
1206                     nel:5001,set_field:192.168.1.1->tun_dst,3  send  the same
1207                     tunnel traffic.
1208
1209              Intermediate models.
1210                     Ports may be  configured  as  partially  flow-based.  For
1211                     example,  one may define an OpenFlow port that represents
1212                     tunnels between a pair of endpoints but leaves  the  flow
1213                     table to discriminate on the flow key.
1214
1215       ovs-vswitchd.conf.db(5)  describes all the details of tunnel configura‐
1216       tion.
1217
1218       These fields do not have any prerequisites, which means that a flow may
1219       match on any or all of them, in any combination.
1220
1221       These fields are zeros for packets that did not arrive on a tunnel.
1222
1223       Tunnel ID Field
1224
1225       Name:            tun_id (aka tunnel_id)
1226       Width:           64 bits
1227       Format:          hexadecimal
1228       Masking:         arbitrary bitwise masks
1229       Prerequisites:   none
1230       Access:          read/write
1231       OpenFlow 1.0:    not supported
1232
1233       OpenFlow 1.1:    not supported
1234       OXM:             OXM_OF_TUNNEL_ID  (38)  since  OpenFlow  1.3  and Open
1235                        vSwitch 1.10
1236       NXM:             NXM_NX_TUN_ID (16) since Open vSwitch 1.1
1237
1238       Many kinds of tunnels support a tunnel ID:
1239
1240              ·      VXLAN and Geneve have a 24-bit virtual network identifier
1241                     (VNI).
1242
1243              ·      LISP has a 24-bit instance ID.
1244
1245              ·      GRE has an optional 32-bit key.
1246
1247              ·      STT has a 64-bit key.
1248
1249              ·      ERSPAN has a 10-bit key (Session ID).
1250
1251       When a packet is received from a tunnel, this field holds the tunnel ID
1252       in its least significant bits, zero-extended to fit. This field is zero
1253       if  the tunnel does not support an ID, or if no ID is in use for a tun‐
1254       nel type that has an optional ID, or if an ID of zero received,  or  if
1255       the packet was not received over a tunnel.
1256
1257       When  a  packet  is  output  to a tunnel port, the tunnel configuration
1258       determines whether the tunnel ID is taken from this field or bound to a
1259       fixed  value. See the earlier description of ``port-based’’ and ``flow-
1260       based’’ tunnels for more information.
1261
1262       The following diagram shows the origin of this field in a typical keyed
1263       GRE tunnel:
1264
1265          Ethernet            IPv4               GRE           Ethernet
1266        <----------->   <--------------->   <------------>   <---------->
1267        48  48   16           8   32  32    16    16   32    48  48   16
1268       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1269       |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1270       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1271                0x800        47                 0x6558
1272
1273
1274       Tunnel IPv4 Source Field
1275
1276       Name:            tun_src
1277       Width:           32 bits
1278       Format:          IPv4
1279       Masking:         arbitrary bitwise masks
1280       Prerequisites:   none
1281       Access:          read/write
1282       OpenFlow 1.0:    not supported
1283       OpenFlow 1.1:    not supported
1284       OXM:             none
1285       NXM:             NXM_NX_TUN_IPV4_SRC (31) since Open vSwitch 2.0
1286
1287       When  a  packet  is  received  from  a tunnel, this field is the source
1288       address in the outer IP header of the tunneled packet.  This  field  is
1289       zero if the packet was not received over a tunnel.
1290
1291       When  a packet is output to a flow-based tunnel port, this field influ‐
1292       ences the IPv4 source address used to send the packet. If it  is  zero,
1293       then the kernel chooses an appropriate IP address based using the rout‐
1294       ing table.
1295
1296       The following diagram shows the origin of this field in a typical keyed
1297       GRE tunnel:
1298
1299          Ethernet            IPv4               GRE           Ethernet
1300        <----------->   <--------------->   <------------>   <---------->
1301        48  48   16           8   32  32    16    16   32    48  48   16
1302       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1303       |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1304       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1305                0x800        47                 0x6558
1306
1307
1308       Tunnel IPv4 Destination Field
1309
1310       Name:            tun_dst
1311       Width:           32 bits
1312       Format:          IPv4
1313       Masking:         arbitrary bitwise masks
1314       Prerequisites:   none
1315       Access:          read/write
1316
1317       OpenFlow 1.0:    not supported
1318       OpenFlow 1.1:    not supported
1319       OXM:             none
1320       NXM:             NXM_NX_TUN_IPV4_DST (32) since Open vSwitch 2.0
1321
1322       When  a packet is received from a tunnel, this field is the destination
1323       address in the outer IP header of the tunneled packet.  This  field  is
1324       zero if the packet was not received over a tunnel.
1325
1326       When  a packet is output to a flow-based tunnel port, this field speci‐
1327       fies the destination to which the tunnel packet is sent.
1328
1329       The following diagram shows the origin of this field in a typical keyed
1330       GRE tunnel:
1331
1332          Ethernet            IPv4               GRE           Ethernet
1333        <----------->   <--------------->   <------------>   <---------->
1334        48  48   16           8   32  32    16    16   32    48  48   16
1335       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1336       |dst|src|type | |...|proto|src|dst| |...| type |key| |dst|src|type| ...
1337       +---+---+-----+ +---+-----+---+---+ +---+------+---+ +---+---+----+
1338                0x800        47                 0x6558
1339
1340
1341       Tunnel IPv6 Source Field
1342
1343       Name:            tun_ipv6_src
1344
1345       Width:           128 bits
1346       Format:          IPv6
1347       Masking:         arbitrary bitwise masks
1348       Prerequisites:   none
1349       Access:          read/write
1350       OpenFlow 1.0:    not supported
1351       OpenFlow 1.1:    not supported
1352       OXM:             none
1353       NXM:             NXM_NX_TUN_IPV6_SRC (109) since Open vSwitch 2.5
1354
1355       Similar to tun_src, but for tunnels over IPv6.
1356
1357       Tunnel IPv6 Destination Field
1358
1359       Name:            tun_ipv6_dst
1360       Width:           128 bits
1361       Format:          IPv6
1362       Masking:         arbitrary bitwise masks
1363       Prerequisites:   none
1364       Access:          read/write
1365       OpenFlow 1.0:    not supported
1366       OpenFlow 1.1:    not supported
1367       OXM:             none
1368       NXM:             NXM_NX_TUN_IPV6_DST (110) since Open vSwitch 2.5
1369
1370       Similar to tun_dst, but for tunnels over IPv6.
1371
1372   VXLAN Group-Based Policy Fields
1373       The VXLAN header is defined as follows [RFC 7348], where the I bit must
1374       be set to 1, unlabeled bits or those labeled reserved must be set to 0,
1375       and Open vSwitch makes the VNI available via tun_id:
1376
1377          VXLAN flags
1378        <------------->
1379        1 1 1 1 1 1 1 1    24    24     8
1380       +-+-+-+-+-+-+-+-+--------+---+--------+
1381       | | | | |I| | | |reserved|VNI|reserved|
1382       +-+-+-+-+-+-+-+-+--------+---+--------+
1383
1384
1385       VXLAN Group-Based Policy [VXLAN Group Policy Option] adds new interpre‐
1386       tations to existing bits in the VXLAN header, reinterpreting it as fol‐
1387       lows, with changes highlighted:
1388
1389           GBP flags
1390        <------------->
1391        1 1 1 1 1 1 1 1       24        24     8
1392       +-+-+-+-+-+-+-+-+---------------+---+--------+
1393       | |D| | |A| | | |group policy ID|VNI|reserved|
1394       +-+-+-+-+-+-+-+-+---------------+---+--------+
1395
1396
1397       Open vSwitch makes GBP fields and flags available through the following
1398       fields. Only packets that arrive over  a  VXLAN  tunnel  with  the  GBP
1399       extension enabled have these fields set. In other packets they are zero
1400       on receive and ignored on transmit.
1401
1402       VXLAN Group-Based Policy ID Field
1403
1404       Name:            tun_gbp_id
1405       Width:           16 bits
1406
1407       Format:          decimal
1408       Masking:         arbitrary bitwise masks
1409       Prerequisites:   none
1410       Access:          read/write
1411       OpenFlow 1.0:    not supported
1412       OpenFlow 1.1:    not supported
1413       OXM:             none
1414       NXM:             NXM_NX_TUN_GBP_ID (38) since Open vSwitch 2.4
1415
1416       For a packet tunneled over VXLAN  with  the  Group-Based  Policy  (GBP)
1417       extension, this field represents the GBP policy ID, as shown above.
1418
1419       VXLAN Group-Based Policy Flags Field
1420
1421       Name:            tun_gbp_flags
1422
1423       Width:           8 bits
1424       Format:          hexadecimal
1425       Masking:         arbitrary bitwise masks
1426       Prerequisites:   none
1427       Access:          read/write
1428       OpenFlow 1.0:    not supported
1429       OpenFlow 1.1:    not supported
1430       OXM:             none
1431       NXM:             NXM_NX_TUN_GBP_FLAGS (39) since Open vSwitch 2.4
1432
1433       For  a  packet  tunneled  over  VXLAN with the Group-Based Policy (GBP)
1434       extension, this field represents the GBP policy flags, as shown above.
1435
1436       The field has the format shown below:
1437
1438           GBP Flags
1439        <------------->
1440        1 1 1 1 1 1 1 1
1441       +-+-+-+-+-+-+-+-+
1442       | |D| | |A| | | |
1443       +-+-+-+-+-+-+-+-+
1444
1445
1446       Unlabeled bits are reserved and must be transmitted as 0. The VXLAN GBP
1447       draft defines the other bits’ meanings as:
1448
1449              D (Don’t Learn)
1450                     When  set, this bit indicates that the egress tunnel end‐
1451                     point must not learn the source address of  the  encapsu‐
1452                     lated frame.
1453
1454              A (Applied)
1455                     When  set,  indicates  that  the group policy has already
1456                     been applied to this packet. Devices must not apply poli‐
1457                     cies when the A bit is set.
1458
1459   ERSPAN Metadata Fields
1460       These  fields provide access to features in the ERSPAN tunneling proto‐
1461       col [ERSPAN], which has two major versions: version 1 (aka type II) and
1462       version 2 (aka type III).
1463
1464       Regardless of version, ERSPAN is encapsulated within a fixed 8-byte GRE
1465       header that consists of a 4-byte GRE base header and a 4-byte  sequence
1466       number. The ERSPAN version 1 header format is:
1467
1468             GRE                ERSPAN v1            Ethernet
1469        <------------>   <--------------------->   <---------->
1470        16    16   32     4  18    10    12  20    48  48   16
1471       +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1472       |...| type |seq| |ver|...|session|...|idx| |dst|src|type| ...
1473       +---+------+---+ +---+---+-------+---+---+ +---+---+----+
1474            0x88be        1      tun_id
1475
1476
1477       The ERSPAN version 2 header format is:
1478
1479             GRE                         ERSPAN v2                      Ethernet
1480        <------------>   <---------------------------------------->   <---------->
1481        16    16   32     4  18    10       32     22   6    1   3    48  48   16
1482       +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1483       |...| type |seq| |ver|...|session|timestamp|...|hwid|dir|...| |dst|src|type| ...
1484       +---+------+---+ +---+---+-------+---------+---+----+---+---+ +---+---+----+
1485            0x22eb        2      tun_id                     0/1
1486
1487
1488       ERSPAN Version Field
1489
1490       Name:            tun_erspan_ver
1491       Width:           8 bits (only the least-significant 4 bits may be nonzero)
1492
1493       Format:          decimal
1494       Masking:         arbitrary bitwise masks
1495       Prerequisites:   none
1496       Access:          read/write
1497       OpenFlow 1.0:    not supported
1498       OpenFlow 1.1:    not supported
1499       OXM:             none
1500       NXM:             NXOXM_ET_ERSPAN_VER (12) since Open vSwitch 2.10
1501
1502       ERSPAN version number: 1 for version 1, or 2 for version 2.
1503
1504       ERSPAN Index Field
1505
1506       Name:            tun_erspan_idx
1507       Width:           32 bits (only the least-significant 20 bits may be nonzero)
1508       Format:          hexadecimal
1509       Masking:         arbitrary bitwise masks
1510
1511       Prerequisites:   none
1512       Access:          read/write
1513       OpenFlow 1.0:    not supported
1514       OpenFlow 1.1:    not supported
1515       OXM:             none
1516       NXM:             NXOXM_ET_ERSPAN_IDX (11) since Open vSwitch 2.10
1517
1518       This  field  is  a  20-bit index/port number associated with the ERSPAN
1519       traffic’s source port and direction  (ingress/egress).  This  field  is
1520       platform dependent.
1521
1522       ERSPAN Direction Field
1523
1524       Name:            tun_erspan_dir
1525       Width:           8 bits (only the least-significant 1 bits may be nonzero)
1526       Format:          decimal
1527       Masking:         arbitrary bitwise masks
1528
1529       Prerequisites:   none
1530       Access:          read/write
1531       OpenFlow 1.0:    not supported
1532       OpenFlow 1.1:    not supported
1533       OXM:             none
1534       NXM:             NXOXM_ET_ERSPAN_DIR (13) since Open vSwitch 2.10
1535
1536       For ERSPAN v2, the mirrored traffic’s direction: 0 for ingress traffic,
1537       1 for egress traffic.
1538
1539       ERSPAN Hardware ID Field
1540
1541       Name:            tun_erspan_hwid
1542       Width:           8 bits (only the least-significant 6 bits may be nonzero)
1543       Format:          hexadecimal
1544       Masking:         arbitrary bitwise masks
1545       Prerequisites:   none
1546
1547       Access:          read/write
1548       OpenFlow 1.0:    not supported
1549       OpenFlow 1.1:    not supported
1550       OXM:             none
1551       NXM:             NXOXM_ET_ERSPAN_HWID (14) since Open vSwitch 2.10
1552
1553       A 6-bit unique identifier of an ERSPAN v2 engine within a system.
1554
1555   Geneve Fields
1556       These fields provide access to additional features in the  Geneve  tun‐
1557       neling  protocol [Geneve]. Their names are somewhat generic in the hope
1558       that the same fields could be reused for other protocols in the future;
1559       for  example, the NSH protocol [NSH] supports TLV options whose form is
1560       identical to that for Geneve options.
1561
1562       Generic Tunnel Option 0 Field
1563
1564
1565       Name:            tun_metadata0
1566       Width:           992 bits (124 bytes)
1567       Format:          hexadecimal
1568       Masking:         arbitrary bitwise masks
1569       Prerequisites:   none
1570       Access:          read/write
1571       OpenFlow 1.0:    not supported
1572       OpenFlow 1.1:    not supported
1573       OXM:             none
1574       NXM:             NXM_NX_TUN_METADATA0 (40) since Open vSwitch 2.5
1575
1576       The above information specifically covers generic tunnel option 0,  but
1577       Open  vSwitch  supports  64  options,  numbered 0 through 63, whose NXM
1578       field numbers are 40 through 103.
1579
1580       These fields provide OpenFlow access to the  generic  type-length-value
1581       options  defined  by  the  Geneve tunneling protocol or other protocols
1582       with options in the same TLV format as Geneve options.  Each  of  these
1583       options has the following wire format:
1584
1585               header                 body
1586        <-------------------> <------------------>
1587         16    8    3    5    4×(length - 1) bytes
1588       +-----+----+---+------+--------------------+
1589       |class|type|res|length|       value        |
1590       +-----+----+---+------+--------------------+
1591                    0
1592
1593
1594       Taken together, the class and type in the option format mean that there
1595       are about 16 million distinct kinds of TLV options, too  many  to  give
1596       individual  OXM  code  points.  Thus, Open vSwitch requires the user to
1597       define the TLV options of interest, by binding up to 64 TLV options  to
1598       generic  tunnel  option NXM code points. Each option may have up to 124
1599       bytes in its body, the maximum allowed by the  TLV  format,  but  bound
1600       options may total at most 252 bytes of body.
1601
1602       Open  vSwitch  extensions  to the OpenFlow protocol bind TLV options to
1603       NXM code points. The ovs-ofctl(8) program offers one way to  use  these
1604       extensions,  e.g.  to  configure a mapping from a TLV option with class
1605       0xffff, type 0, and a body length of 4 bytes:
1606
1607       ovs-ofctl add-tlv-map br0 "{class=0xffff,type=0,len=4}->tun_metadata0"
1608
1609
1610       Once a TLV option is properly bound, it can be  accessed  and  modified
1611       like any other field, e.g. to send packets that have value 1234 for the
1612       option described above to the controller:
1613
1614       ovs-ofctl add-flow br0 tun_metadata0=1234,actions=controller
1615
1616
1617       An option not received or not bound is matched as all zeros.
1618
1619       Tunnel Flags Field
1620
1621       Name:            tun_flags
1622       Width:           16 bits (only the least-significant 1 bits may be nonzero)
1623       Format:          tunnel flags
1624       Masking:         arbitrary bitwise masks
1625       Prerequisites:   none
1626       Access:          read/write
1627       OpenFlow 1.0:    not supported
1628       OpenFlow 1.1:    not supported
1629       OXM:             none
1630       NXM:             NXM_NX_TUN_FLAGS (104) since Open vSwitch 2.5
1631
1632       Flags indicating various aspects of the tunnel encapsulation.
1633
1634       Matches on this field are most conveniently written in  terms  of  sym‐
1635       bolic names (given in the diagram below), each preceded by either + for
1636       a flag that must be set, or - for a flag that must  be  unset,  without
1637       any  other  delimiters between the flags. Flags not mentioned are wild‐
1638       carded. For example, tun_flags=+oam matches only OAM  packets.  Matches
1639       can also be written as flags/mask, where flags and mask are 16-bit num‐
1640       bers in decimal or in hexadecimal prefixed by 0x.
1641
1642       Currently, only one flag is defined:
1643
1644              oam    The tunnel protocol indicated that this is an OAM (Opera‐
1645                     tions and Management) control packet.
1646
1647       The switch may reject matches against unknown flags.
1648
1649       Newer  versions of Open vSwitch may introduce additional flags with new
1650       meanings. It is therefore not recommended to use an exact match on this
1651       field  since  the  behavior of these new flags is unknown and should be
1652       ignored.
1653
1654       For non-tunneled packets, the value is 0.

METADATA FIELDS

1656   Summary:
1657       Name            Bytes   Mask   RW?   Prereqs   NXM/OXM Support
1658
1659       ──────────────  ──────  ─────  ────  ────────  ─────────────────────
1660       in_port         2       no     yes   none      OVS 1.1+
1661       in_port_oxm     4       no     yes   none      OF 1.2+ and OVS 1.7+
1662
1663       skb_priority    4       no     no    none
1664       pkt_mark        4       yes    yes   none      OVS 2.0+
1665       actset_output   4       no     no    none      OF 1.3+ and OVS 2.4+
1666
1667       packet_type     4       no     no    none      OF 1.5+ and OVS 2.8+
1668
1669       These fields relate to the origin or treatment of a  packet,  but  they
1670       are not extracted from the packet data itself.
1671
1672       Ingress Port Field
1673
1674
1675       Name:            in_port
1676       Width:           16 bits
1677       Format:          OpenFlow 1.0 port
1678
1679       Masking:         not maskable
1680       Prerequisites:   none
1681       Access:          read/write
1682
1683       OpenFlow 1.0:    yes (exact match only)
1684       OpenFlow 1.1:    yes (exact match only)
1685       OXM:             none
1686
1687       NXM:             NXM_OF_IN_PORT (0) since Open vSwitch 1.1
1688
1689       The  OpenFlow port on which the packet being processed arrived. This is
1690       a 16-bit field that holds an OpenFlow 1.0 port number. For receiving  a
1691       packet, the only values that appear in this field are:
1692
1693              1 through 0xfeff (65,279), inclusive.
1694                     Conventional OpenFlow port numbers.
1695
1696              OFPP_LOCAL (0xfffe or 65,534).
1697                     The ``local’’ port, which in Open vSwitch is always named
1698                     the same as the bridge itself. This represents a  connec‐
1699                     tion  between the switch and the local TCP/IP stack. This
1700                     port is where an IP address is most  commonly  configured
1701                     on an Open vSwitch switch.
1702
1703                     OpenFlow  does not require a switch to have a local port,
1704                     but all existing versions of  Open  vSwitch  have  always
1705                     included a local port. Future Directions: Future versions
1706                     of Open vSwitch might be  able  to  optionally  omit  the
1707                     local  port,  if someone submits code to implement such a
1708                     feature.
1709
1710              OFPP_NONE (OpenFlow 1.0) or OFPP_ANY (OpenFlow 1.1+) (0xffff  or
1711              65,535).
1712              OFPP_CONTROLLER (0xfffd or 65,533).
1713                   When  a controller injects a packet into an OpenFlow switch
1714                   with a ``packet-out’’ request, it can specify one of  these
1715                   ingress  ports  to  indicate  that the packet was generated
1716                   internally rather than having been received on some port.
1717
1718                   OpenFlow 1.0 specified OFPP_NONE for this purpose.  Despite
1719                   that,  some  controllers  used  OFPP_CONTROLLER,  and  some
1720                   switches only accepted OFPP_CONTROLLER, so  OpenFlow  1.0.2
1721                   required  support  for  both  ports. OpenFlow 1.1 and later
1722                   were more clearly drafted to  allow  only  OFPP_CONTROLLER.
1723                   For  maximum  compatibility, Open vSwitch allows both ports
1724                   with all OpenFlow versions.
1725
1726       Values not mentioned above will never appear when receiving  a  packet,
1727       including the following notable values:
1728
1729              0      Zero is not a valid OpenFlow port number.
1730
1731              OFPP_MAX (0xff00 or 65,280).
1732                     This  value  has  only  been clearly specified as a valid
1733                     port number as of OpenFlow 1.3.3. Before that, its status
1734                     was  unclear,  and  so  Open  vSwitch  has  never allowed
1735                     OFPP_MAX to be used as a port  number,  so  packets  will
1736                     never be received on this port. (Other OpenFlow switches,
1737                     of course, might use it.)
1738
1739              OFPP_UNSET (0xfff7 or 65,527)
1740              OFPP_IN_PORT (0xfff8 or 65,528)
1741              OFPP_TABLE (0xfff9 or 65,529)
1742              OFPP_NORMAL (0xfffa or 65,530)
1743              OFPP_FLOOD (0xfffb or 65,531)
1744              OFPP_ALL (0xfffc or 65,532)
1745                   These port numbers are used  only  in  output  actions  and
1746                   never appear as ingress ports.
1747
1748                   Most  of  these  port numbers were defined in OpenFlow 1.0,
1749                   but OFPP_UNSET was only introduced in OpenFlow 1.5.
1750
1751       Values that will never appear when receiving  a  packet  may  still  be
1752       matched  against  in  the  flow table. There are still circumstances in
1753       which those flows can be matched:
1754
1755              ·      The resubmit Open vSwitch extension action allows a  flow
1756                     table lookup with an arbitrary ingress port.
1757
1758              ·      An  action  that  modifies  the  ingress  port field (see
1759                     below), such as e.g. load or set_field,  followed  by  an
1760                     action  or  instruction  that performs another flow table
1761                     lookup, such as resubmit or goto_table.
1762
1763       This field is heavily used for matching in  OpenFlow  tables,  but  for
1764       packet egress, it has only very limited roles:
1765
1766              ·      OpenFlow  requires suppressing output actions to in_port.
1767                     That is, the following two flows both  drop  all  packets
1768                     that arrive on port 1:
1769
1770                     in_port=1,actions=1
1771                     in_port=1,actions=drop
1772
1773
1774                     (This  behavior  is occasionally useful for flooding to a
1775                     subset of ports. Specifying actions=1,2,3,4, for example,
1776                     outputs  to  ports  1,  2, 3, and 4, omitting the ingress
1777                     port.)
1778
1779              ·      OpenFlow has a  special  port  OFPP_IN_PORT  (with  value
1780                     0xfff8) that outputs to the ingress port. For example, in
1781                     a switch that  has  four  ports  numbered  1  through  4,
1782                     actions=1,2,3,4,in_port  outputs to ports 1, 2, 3, and 4,
1783                     including the ingress port.
1784
1785       Because the ingress port field has so little influence on  packet  pro‐
1786       cessing,  it  does not ordinarily make sense to modify the ingress port
1787       field. The field is writable only to support the  occasional  use  case
1788       where  the  ingress  port’s  roles  in  packet egress, described above,
1789       become troublesome. For example,  actions=load:0->NXM_OF_IN_PORT[],out‐
1790       put:123  will  output  to  port  123 regardless of whether it is in the
1791       ingress port. If the ingress port is important, then one may  save  and
1792       restore it on the stack:
1793
1794       actions=push:NXM_OF_IN_PORT[],load:0->NXM_OF_IN_PORT[],output:123,pop:NXM_OF_IN_PORT[]
1795
1796
1797       or,  in  Open  vSwitch  2.7  or later, use the clone action to save and
1798       restore it:
1799
1800       actions=clone(load:0->NXM_OF_IN_PORT[],output:123)
1801
1802
1803       The ability to modify the ingress port is an Open vSwitch extension  to
1804       OpenFlow.
1805
1806       OXM Ingress Port Field
1807
1808       Name:            in_port_oxm
1809       Width:           32 bits
1810       Format:          OpenFlow 1.1+ port
1811
1812       Masking:         not maskable
1813       Prerequisites:   none
1814       Access:          read/write
1815       OpenFlow 1.0:    not supported
1816       OpenFlow 1.1:    yes (exact match only)
1817       OXM:             OXM_OF_IN_PORT (0) since OpenFlow 1.2 and Open vSwitch
1818                        1.7
1819       NXM:             none
1820
1821       OpenFlow 1.1 and later use a 32-bit port number, so this field supplies
1822       a  32-bit  view  of  the ingress port. Current versions of Open vSwitch
1823       support only a 16-bit range of ports:
1824
1825              ·      OpenFlow 1.0 ports 0x0000 to 0xfeff,  inclusive,  map  to
1826                     OpenFlow 1.1 port numbers with the same values.
1827
1828              ·      OpenFlow  1.0  ports  0xff00 to 0xffff, inclusive, map to
1829                     OpenFlow 1.1 port numbers 0xffffff00 to 0xffffffff.
1830
1831              ·      OpenFlow 1.1  ports  0x0000ff00  to  0xfffffeff  are  not
1832                     mapped and not supported.
1833
1834       in_port  and  in_port_oxm are two views of the same information, so all
1835       of the comments on in_port apply to in_port_oxm too. Modifying  in_port
1836       changes in_port_oxm, and vice versa.
1837
1838       Setting  in_port_oxm  to an unsupported value yields unspecified behav‐
1839       ior.
1840
1841       Output Queue Field
1842
1843       Name:            skb_priority
1844       Width:           32 bits
1845       Format:          hexadecimal
1846       Masking:         not maskable
1847       Prerequisites:   none
1848       Access:          read-only
1849       OpenFlow 1.0:    not supported
1850
1851       OpenFlow 1.1:    not supported
1852       OXM:             none
1853       NXM:             none
1854
1855       Future Directions: Open vSwitch implements the output queue as a field,
1856       but  does  not currently expose it through OXM or NXM for matching pur‐
1857       poses. If this turns out to be a useful feature,  it  could  be  imple‐
1858       mented  in  future versions. Only the set_queue, enqueue, and pop_queue
1859       actions currently influence the output queue.
1860
1861       This field influences how packets in the flow will be queued, for qual‐
1862       ity  of  service (QoS) purposes, when they egress the switch. Its range
1863       of meaningful values, and their meanings, varies greatly from one Open‐
1864       Flow  implementation  to  another. Even within a single implementation,
1865       there is no guarantee that all OpenFlow ports have the same queues con‐
1866       figured  or that all OpenFlow ports in an implementation can be config‐
1867       ured the same way queue-wise.
1868
1869       Configuring queues on OpenFlow is not well standardized. On Linux, Open
1870       vSwitch  supports  queue  configuration via OVSDB, specifically the QoS
1871       and Queue tables (see ovs-vswitchd.conf.db(5) for  details).  Ports  of
1872       Open  vSwitch  to  other  platforms  might  require queue configuration
1873       through some separate protocol (such as a CLI).  Even  on  Linux,  Open
1874       vSwitch  exposes  only  a  fraction  of  the  kernel’s queuing features
1875       through OVSDB, so advanced or unusual uses might require use  of  sepa‐
1876       rate  utilities  (e.g.  tc).  OpenFlow switches other than Open vSwitch
1877       might use OF-CONFIG or  any  of  the  configuration  methods  mentioned
1878       above.  Finally,  some  OpenFlow switches have a fixed number of fixed-
1879       function queues (e.g. eight queues with  strictly  defined  priorities)
1880       and others do not support any control over queuing.
1881
1882       The only output queue that all OpenFlow implementations must support is
1883       zero, to identify a default queue, whose properties are implementation-
1884       defined. Outputting a packet to a queue that does not exist on the out‐
1885       put port yields unpredictable behavior:  among  the  possibilities  are
1886       that  the  packet  might  be dropped or transmitted with a very high or
1887       very low priority.
1888
1889       OpenFlow 1.0 only allowed output queues to be specified as part  of  an
1890       enqueue action that specified both a queue and an output port. That is,
1891       OpenFlow 1.0 treats the queue as an argument to an  action,  not  as  a
1892       field.
1893
1894       To increase flexibility, OpenFlow 1.1 added an action to set the output
1895       queue. This model was carried forward, without change, through OpenFlow
1896       1.5.
1897
1898       Open  vSwitch implements the native queuing model of each OpenFlow ver‐
1899       sion it supports. Open vSwitch also includes an extension  for  setting
1900       the output queue as an action in OpenFlow 1.0.
1901
1902       When  a  packet  ingresses into an OpenFlow switch, the output queue is
1903       ordinarily set to  0,  indicating  the  default  queue.  However,  Open
1904       vSwitch  supports  various  ways  to forward a packet from one OpenFlow
1905       switch to another within a single host. In these  cases,  Open  vSwitch
1906       maintains the output queue across the forwarding step. For example:
1907
1908              ·      A  hop  across an Open vSwitch ``patch port’’ (which does
1909                     not actually involve queuing) preserves the output queue.
1910
1911              ·      When a flow sets the output  queue  then  outputs  to  an
1912                     OpenFlow  tunnel  port,  the  encapsulation preserves the
1913                     output queue. If  the  kernel  TCP/IP  stack  routes  the
1914                     encapsulated  packet  directly  to  a physical interface,
1915                     then that output honors the output queue.  Alternatively,
1916                     if  the  kernel routes the encapsulated packet to another
1917                     Open vSwitch bridge, then the output queue set previously
1918                     becomes the initial output queue on ingress to the second
1919                     bridge and will thus be used for further  output  actions
1920                     (unless overridden by a new ``set queue’’ action).
1921
1922                     (This  description  reflects the current behavior of Open
1923                     vSwitch on Linux. This behavior relies on details of  the
1924                     Linux  TCP/IP  stack. It could be difficult to make ports
1925                     to other operating systems behave the same way.)
1926
1927       Packet Mark Field
1928
1929       Name:            pkt_mark
1930       Width:           32 bits
1931       Format:          hexadecimal
1932       Masking:         arbitrary bitwise masks
1933       Prerequisites:   none
1934       Access:          read/write
1935       OpenFlow 1.0:    not supported
1936       OpenFlow 1.1:    not supported
1937       OXM:             none
1938       NXM:             NXM_NX_PKT_MARK (33) since Open vSwitch 2.0
1939
1940       Packet mark comes to Open vSwitch from the Linux kernel, in  which  the
1941       sk_buff  data structure that represents a packet contains a 32-bit mem‐
1942       ber named skb_mark. The value of skb_mark  propagates  along  with  the
1943       packet it accompanies wherever the packet goes in the kernel. It has no
1944       predefined semantics but various kernel-user  interfaces  can  set  and
1945       match  on  it,  which  makes it suitable for ``marking’’ packets at one
1946       point in their handling and then acting on the mark later.  With  ipta‐
1947       bles,  for  example, one can mark some traffic specially at ingress and
1948       then handle that traffic differently at  egress  based  on  the  marked
1949       value.
1950
1951       Packet  mark  is an attempt at a generalization of the skb_mark concept
1952       beyond Linux, at least through more generic naming. Like  skb_priority,
1953       packet  mark  is  preserved  across  forwarding steps within a machine.
1954       Unlike skb_priority, packet mark has no direct effect  on  packet  for‐
1955       warding: the value set in packet mark does not matter unless some later
1956       OpenFlow table or switch matches on packet mark, or unless  the  packet
1957       passes  through some other kernel subsystem that has been configured to
1958       interpret packet mark in specific ways, e.g. through iptables  configu‐
1959       ration mentioned above.
1960
1961       Preserving packet mark across kernel forwarding steps relies heavily on
1962       kernel support, which ports to  non-Linux  operating  systems  may  not
1963       have.  Regardless  of  operating  system support, Open vSwitch supports
1964       packet mark within a single bridge and across patch ports.
1965
1966       The value of packet mark when a packet ingresses into  the  first  Open
1967       vSwich  bridge  is typically zero, but it could be nonzero if its value
1968       was previously set by some kernel subsystem.
1969
1970       Action Set Output Port Field
1971
1972       Name:            actset_output
1973       Width:           32 bits
1974       Format:          OpenFlow 1.1+ port
1975       Masking:         not maskable
1976       Prerequisites:   none
1977       Access:          read-only
1978       OpenFlow 1.0:    not supported
1979       OpenFlow 1.1:    not supported
1980
1981       OXM:             ONFOXM_ET_ACTSET_OUTPUT (43) since  OpenFlow  1.3  and
1982                        Open  vSwitch  2.4;  OXM_OF_ACTSET_OUTPUT  (43)  since
1983                        OpenFlow 1.5 and Open vSwitch 2.4
1984       NXM:             none
1985
1986       Holds the output port currently in the OpenFlow action set  (i.e.  from
1987       an  output  action within a write_actions instruction). Its value is an
1988       OpenFlow port number. If there is no output port in the OpenFlow action
1989       set,  or  if  the output port will be ignored (e.g. because there is an
1990       output group in the OpenFlow  action  set),  then  the  value  will  be
1991       OFPP_UNSET.
1992
1993       Open  vSwitch  allows any table to match this field. OpenFlow, however,
1994       only requires this field to be matchable from within an OpenFlow egress
1995       table (a feature that Open vSwitch does not yet implement).
1996
1997       Packet Type Field
1998
1999       Name:            packet_type
2000       Width:           32 bits
2001       Format:          packet type
2002       Masking:         not maskable
2003       Prerequisites:   none
2004       Access:          read-only
2005       OpenFlow 1.0:    not supported
2006
2007       OpenFlow 1.1:    not supported
2008       OXM:             OXM_OF_PACKET_TYPE  (44)  since  OpenFlow 1.5 and Open
2009                        vSwitch 2.8
2010       NXM:             none
2011
2012       The type of the packet in the format specified in OpenFlow 1.5:
2013
2014        Packet type
2015        <--------->
2016        16    16
2017       +---+-------+
2018       |ns |ns_type| ...
2019       +---+-------+
2020
2021
2022       The upper 16 bits, ns, are a namespace. The meaning of ns_type  depends
2023       on  the  namespace. The packet type field is specified and displayed in
2024       the format (ns,ns_type).
2025
2026       Open vSwitch currently supports the following classes of  packet  types
2027       for matching:
2028
2029              (0,0)  Ethernet.
2030
2031              (1,ethertype)
2032                     The specified ethertype. Open vSwitch can forward packets
2033                     with any ethertype, but it can only match on and  process
2034                     data fields for the following supported packet types:
2035
2036                     (1,0x800)
2037                            IPv4
2038
2039                     (1,0x806)
2040                            ARP
2041
2042                     (1,0x86dd)
2043                            IPv6
2044
2045                     (1,0x8847)
2046                            MPLS
2047
2048                     (1,0x8848)
2049                            MPLS multicast
2050
2051                     (1,0x8035)
2052                            RARP
2053
2054                     (1,0x894f)
2055                            NSH
2056
2057       Consider  the  distinction  between  a  packet  with packet_type=(0,0),
2058       dl_type=0x800 and one with packet_type=(1,0x800). The former is an Eth‐
2059       ernet frame that contains an IPv4 packet, like this:
2060
2061          Ethernet            IPv4
2062        <----------->   <--------------->
2063        48  48   16           8   32  32
2064       +---+---+-----+ +---+-----+---+---+
2065       |dst|src|type | |...|proto|src|dst| ...
2066       +---+---+-----+ +---+-----+---+---+
2067                0x800
2068
2069
2070       The  latter  is an IPv4 packet not encapsulated inside any outer frame,
2071       like this:
2072
2073              IPv4
2074        <--------------->
2075              8   32  32
2076       +---+-----+---+---+
2077       |...|proto|src|dst| ...
2078       +---+-----+---+---+
2079
2080
2081       Matching on packet_type is a pre-requisite for  matching  on  any  data
2082       field,  but for backward compatibility, when a match on a data field is
2083       present without a packet_type match, Open  vSwitch  acts  as  though  a
2084       match  on  (0,0)  (Ethernet)  had  been  supplied. Similarly, when Open
2085       vSwitch sends flow match information to a controller, e.g. in  a  reply
2086       to  a  request  to  dump  the flow table, Open vSwitch omits a match on
2087       packet type (0,0) if it would be implied by a data field match.
2088

CONNECTION TRACKING FIELDS

2090   Summary:
2091       Name          Bytes   Mask   RW?   Prereqs   NXM/OXM Support
2092       ────────────  ──────  ─────  ────  ────────  ────────────────
2093       ct_state      4       yes    no    none      OVS 2.5+
2094       ct_zone       2       no     no    none      OVS 2.5+
2095       ct_mark       4       yes    yes   none      OVS 2.5+
2096       ct_label      16      yes    yes   none      OVS 2.5+
2097       ct_nw_src     4       yes    no    CT        OVS 2.8+
2098       ct_nw_dst     4       yes    no    CT        OVS 2.8+
2099
2100       ct_ipv6_src   16      yes    no    CT        OVS 2.8+
2101       ct_ipv6_dst   16      yes    no    CT        OVS 2.8+
2102       ct_nw_proto   1       no     no    CT        OVS 2.8+
2103       ct_tp_src     2       yes    no    CT        OVS 2.8+
2104       ct_tp_dst     2       yes    no    CT        OVS 2.8+
2105
2106       Open vSwitch 2.5  and  later  support  ``connection  tracking,’’  which
2107       allows  bidirectional  streams of packets to be statefully grouped into
2108       connections. Open vSwitch connection tracking, for example,  identifies
2109       the  patterns  of  TCP  packets that indicates a successfully initiated
2110       connection, as well as those that indicate that a connection  has  been
2111       torn  down.  Open vSwitch connection tracking can also identify related
2112       connections, such as FTP data connections spawned from FTP control con‐
2113       nections.
2114
2115       An  individual packet passing through the pipeline may be in one of two
2116       states, ``untracked’’ or ``tracked,’’ which may  be  distinguished  via
2117       the ``trk’’ flag in ct_state. A packet is untracked at the beginning of
2118       the Open vSwitch pipeline and continues to be untracked until the pipe‐
2119       line  invokes  the  ct  action.  The connection tracking fields are all
2120       zeroes in an untracked packet. When a flow in the Open vSwitch pipeline
2121       invokes  the  ct action, the action initializes the connection tracking
2122       fields and the packet becomes tracked for the remainder of its process‐
2123       ing.
2124
2125       The  connection  tracker  stores connection state in an internal table,
2126       but it only adds a new entry to this table when a ct action for  a  new
2127       connection  invokes  ct  with the commit parameter. For a given connec‐
2128       tion, when a pipeline has executed ct, but not  yet  with  commit,  the
2129       connection  is said to be uncommitted. State for an uncommitted connec‐
2130       tion is ephemeral and does not persist past the end of the pipeline, so
2131       some features are only available to committed connections. A connection
2132       would typically be left uncommitted as a way to drop its packets.
2133
2134       Connection tracking is an Open vSwitch extension to OpenFlow.
2135
2136       Connection Tracking State Field
2137
2138       Name:            ct_state
2139       Width:           32 bits
2140       Format:          ct state
2141       Masking:         arbitrary bitwise masks
2142       Prerequisites:   none
2143       Access:          read-only
2144       OpenFlow 1.0:    not supported
2145       OpenFlow 1.1:    not supported
2146       OXM:             none
2147
2148       NXM:             NXM_NX_CT_STATE (105) since Open vSwitch 2.5
2149
2150       This field holds several flags that can be used to determine the  state
2151       of the connection to which the packet belongs.
2152
2153       Matches  on  this  field are most conveniently written in terms of sym‐
2154       bolic names (listed below), each preceded by either + for a  flag  that
2155       must  be  set,  or  -  for a flag that must be unset, without any other
2156       delimiters between the flags. Flags not mentioned are  wildcarded.  For
2157       example,  tcp,ct_state=+trk-new  matches TCP packets that have been run
2158       through the connection tracker and do not establish a  new  connection.
2159       Matches  can  also  be  written as flags/mask, where flags and mask are
2160       32-bit numbers in decimal or in hexadecimal prefixed by 0x.
2161
2162       The following flags are defined:
2163
2164              new (0x01)
2165                     A new connection. Set to 1 if this is an uncommitted con‐
2166                     nection.
2167
2168              est (0x02)
2169                     Part  of  an  existing  connection. Set to 1 if this is a
2170                     committed connection.
2171
2172              rel (0x04)
2173                     Related to an existing connection, e.g. an ICMP  ``desti‐
2174                     nation  unreachable’’ message or an FTP data connections.
2175                     This flag will only be 1 if the connection to which  this
2176                     one is related is committed.
2177
2178                     Connections identified as rel are separate from the orig‐
2179                     inating connection and must be committed separately.  All
2180                     packets  for  a related connection will have the rel flag
2181                     set, not just the initial packet.
2182
2183              rpl (0x08)
2184                     This packet is in the reply direction, meaning that it is
2185                     in  the opposite direction from the packet that initiated
2186                     the connection. This flag will only be 1 if  the  connec‐
2187                     tion is committed.
2188
2189              inv (0x10)
2190                     The state is invalid, meaning that the connection tracker
2191                     couldn’t identify the connection. This flag is  a  catch-
2192                     all  for  problems  in  the  connection or the connection
2193                     tracker, such as:
2194
2195                     ·      L3/L4 protocol handler is not  loaded/unavailable.
2196                            With the Linux kernel datapath, this may mean that
2197                            the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules
2198                            are not loaded.
2199
2200                     ·      L3/L4  protocol handler determines that the packet
2201                            is malformed.
2202
2203                     ·      Packets are unexpected length for protocol.
2204
2205              trk (0x20)
2206                     This packet is tracked, meaning that  it  has  previously
2207                     traversed  the  connection  tracker.  If this flag is not
2208                     set, then no other flags will be set.  If  this  flag  is
2209                     set,  then the packet is tracked and other flags may also
2210                     be set.
2211
2212              snat (0x40)
2213                     This packet was transformed by source address/port trans‐
2214                     lation  by  a preceding ct action. Open vSwitch 2.6 added
2215                     this flag.
2216
2217              dnat (0x80)
2218                     This packet was transformed by  destination  address/port
2219                     translation  by  a  preceding ct action. Open vSwitch 2.6
2220                     added this flag.
2221
2222       There are additional constraints on these flags, listed  in  decreasing
2223       order of precedence below:
2224
2225              1.  If trk is unset, no other flags are set.
2226
2227              2.  If trk is set, one or more other flags may be set.
2228
2229              3.  If inv is set, only the trk flag is also set.
2230
2231              4.  new and est are mutually exclusive.
2232
2233              5.  new and rpl are mutually exclusive.
2234
2235              6.  rel may be set in conjunction with any other flags.
2236
2237       Future versions of Open vSwitch may define new flags.
2238
2239       Connection Tracking Zone Field
2240
2241       Name:            ct_zone
2242       Width:           16 bits
2243       Format:          hexadecimal
2244       Masking:         not maskable
2245       Prerequisites:   none
2246
2247       Access:          read-only
2248       OpenFlow 1.0:    not supported
2249       OpenFlow 1.1:    not supported
2250       OXM:             none
2251       NXM:             NXM_NX_CT_ZONE (106) since Open vSwitch 2.5
2252
2253       A connection tracking zone, the zone value passed to the most recent ct
2254       action. Each zone is an independent  connection  tracking  context,  so
2255       tracking  the  same  packet  in multiple contexts requires using the ct
2256       action multiple times.
2257
2258       Connection Tracking Mark Field
2259
2260       Name:            ct_mark
2261       Width:           32 bits
2262
2263       Format:          hexadecimal
2264       Masking:         arbitrary bitwise masks
2265       Prerequisites:   none
2266       Access:          read/write
2267       OpenFlow 1.0:    not supported
2268       OpenFlow 1.1:    not supported
2269       OXM:             none
2270       NXM:             NXM_NX_CT_MARK (107) since Open vSwitch 2.5
2271
2272       The metadata committed, by an action within the exec parameter  to  the
2273       ct action, to the connection to which the current packet belongs.
2274
2275       Connection Tracking Label Field
2276
2277       Name:            ct_label
2278
2279       Width:           128 bits
2280       Format:          hexadecimal
2281       Masking:         arbitrary bitwise masks
2282       Prerequisites:   none
2283       Access:          read/write
2284       OpenFlow 1.0:    not supported
2285       OpenFlow 1.1:    not supported
2286       OXM:             none
2287       NXM:             NXM_NX_CT_LABEL (108) since Open vSwitch 2.5
2288
2289       The  label  committed, by an action within the exec parameter to the ct
2290       action, to the connection to which the current packet belongs.
2291
2292       Open vSwitch 2.8 introduced the matching support for connection tracker
2293       original direction 5-tuple fields.
2294
2295       For non-committed non-related connections the conntrack original direc‐
2296       tion tuple fields always have the  same  values  as  the  corresponding
2297       headers in the packet itself. For any other packets of a committed con‐
2298       nection the conntrack original direction tuple fields reflect the  val‐
2299       ues from that initial non-committed non-related packet, and thus may be
2300       different from the actual packet headers, as the actual packet  headers
2301       may  be  in  reverse  direction (for reply packets), transformed by NAT
2302       (when nat option was applied to the connection),  or  be  of  different
2303       protocol  (i.e.,  when  an  ICMP response is sent to an UDP packet). In
2304       case of related connections, e.g., an FTP data connection, the original
2305       direction tuple contains the original direction headers from the master
2306       connection, e.g., an FTP control connection.
2307
2308       The following fields are populated by the  ct  action,  and  require  a
2309       match  to a valid connection tracking state as a prerequisite, in addi‐
2310       tion to the IP or IPv6 ethertype match. Examples  of  valid  connection
2311       tracking    state   matches   include   ct_state=+new,   ct_state=+est,
2312       ct_state=+rel, and ct_state=+trk-inv.
2313
2314       Connection Tracking Original Direction IPv4 Source Address Field
2315
2316       Name:            ct_nw_src
2317       Width:           32 bits
2318       Format:          IPv4
2319       Masking:         arbitrary bitwise masks
2320       Prerequisites:   CT
2321       Access:          read-only
2322       OpenFlow 1.0:    not supported
2323       OpenFlow 1.1:    not supported
2324       OXM:             none
2325       NXM:             NXM_NX_CT_NW_SRC (120) since Open vSwitch 2.8
2326
2327       Matches IPv4 conntrack original direction tuple source address. See the
2328       paragraphs  above  for  general  description  to the conntrack original
2329       direction tuple. Introduced in Open vSwitch 2.8.
2330
2331       Connection Tracking Original Direction IPv4 Destination Address Field
2332
2333       Name:            ct_nw_dst
2334       Width:           32 bits
2335       Format:          IPv4
2336       Masking:         arbitrary bitwise masks
2337       Prerequisites:   CT
2338       Access:          read-only
2339       OpenFlow 1.0:    not supported
2340       OpenFlow 1.1:    not supported
2341       OXM:             none
2342
2343       NXM:             NXM_NX_CT_NW_DST (121) since Open vSwitch 2.8
2344
2345       Matches IPv4 conntrack original direction  tuple  destination  address.
2346       See the paragraphs above for general description to the conntrack orig‐
2347       inal direction tuple. Introduced in Open vSwitch 2.8.
2348
2349       Connection Tracking Original Direction IPv6 Source Address Field
2350
2351       Name:            ct_ipv6_src
2352       Width:           128 bits
2353       Format:          IPv6
2354       Masking:         arbitrary bitwise masks
2355       Prerequisites:   CT
2356       Access:          read-only
2357       OpenFlow 1.0:    not supported
2358
2359       OpenFlow 1.1:    not supported
2360       OXM:             none
2361       NXM:             NXM_NX_CT_IPV6_SRC (122) since Open vSwitch 2.8
2362
2363       Matches IPv6 conntrack original direction tuple source address. See the
2364       paragraphs  above  for  general  description  to the conntrack original
2365       direction tuple. Introduced in Open vSwitch 2.8.
2366
2367       Connection Tracking Original Direction IPv6 Destination Address Field
2368
2369       Name:            ct_ipv6_dst
2370       Width:           128 bits
2371       Format:          IPv6
2372       Masking:         arbitrary bitwise masks
2373       Prerequisites:   CT
2374
2375       Access:          read-only
2376       OpenFlow 1.0:    not supported
2377       OpenFlow 1.1:    not supported
2378       OXM:             none
2379       NXM:             NXM_NX_CT_IPV6_DST (123) since Open vSwitch 2.8
2380
2381       Matches IPv6 conntrack original direction  tuple  destination  address.
2382       See the paragraphs above for general description to the conntrack orig‐
2383       inal direction tuple. Introduced in Open vSwitch 2.8.
2384
2385       Connection Tracking Original Direction IP Protocol Field
2386
2387       Name:            ct_nw_proto
2388       Width:           8 bits
2389       Format:          decimal
2390
2391       Masking:         not maskable
2392       Prerequisites:   CT
2393       Access:          read-only
2394       OpenFlow 1.0:    not supported
2395       OpenFlow 1.1:    not supported
2396       OXM:             none
2397       NXM:             NXM_NX_CT_NW_PROTO (119) since Open vSwitch 2.8
2398
2399       Matches conntrack original direction tuple IP protocol type,  which  is
2400       specified  as  a decimal number between 0 and 255, inclusive (e.g. 1 to
2401       match ICMP packets or 6 to match TCP packets). In case of, for example,
2402       an  ICMP  response  to an UDP packet, this may be different from the IP
2403       protocol type of the packet itself. See the paragraphs above  for  gen‐
2404       eral  description to the conntrack original direction tuple. Introduced
2405       in Open vSwitch 2.8.
2406
2407       Connection Tracking Original  Direction  Transport  Layer  Source  Port
2408       Field
2409
2410       Name:            ct_tp_src
2411       Width:           16 bits
2412       Format:          decimal
2413       Masking:         arbitrary bitwise masks
2414       Prerequisites:   CT
2415       Access:          read-only
2416       OpenFlow 1.0:    not supported
2417       OpenFlow 1.1:    not supported
2418       OXM:             none
2419       NXM:             NXM_NX_CT_TP_SRC (124) since Open vSwitch 2.8
2420
2421       Bitwise  match  on  the  conntrack  original  direction tuple transport
2422       source, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for  UDP,  or  132
2423       for  SCTP. When MFF_CT_NW_PROTO has value 1 for ICMP, or 58 for ICMPv6,
2424       the lower 8 bits of MFF_CT_TP_SRC matches the conntrack original direc‐
2425       tion ICMP type. See the paragraphs above for general description to the
2426       conntrack original direction tuple. Introduced in Open vSwitch 2.8.
2427
2428       Connection Tracking Original  Direction  Transport  Layer  Source  Port
2429       Field
2430
2431       Name:            ct_tp_dst
2432       Width:           16 bits
2433       Format:          decimal
2434       Masking:         arbitrary bitwise masks
2435       Prerequisites:   CT
2436       Access:          read-only
2437       OpenFlow 1.0:    not supported
2438
2439       OpenFlow 1.1:    not supported
2440       OXM:             none
2441       NXM:             NXM_NX_CT_TP_DST (125) since Open vSwitch 2.8
2442
2443       Bitwise  match on the conntrack original direction tuple transport des‐
2444       tination port, when MFF_CT_NW_PROTO has value 6 for TCP, 17 for UDP, or
2445       132  for  SCTP.  When  MFF_CT_NW_PROTO  has value 1 for ICMP, or 58 for
2446       ICMPv6, the lower 8 bits of MFF_CT_TP_DST matches the conntrack  origi‐
2447       nal  direction ICMP code. See the paragraphs above for general descrip‐
2448       tion to the conntrack original  direction  tuple.  Introduced  in  Open
2449       vSwitch 2.8.
2450

REGISTER FIELDS

2452   Summary:
2453       Name       Bytes   Mask   RW?   Prereqs   NXM/OXM Support
2454       ─────────  ──────  ─────  ────  ────────  ─────────────────────
2455       metadata   8       yes    yes   none      OF 1.2+ and OVS 1.8+
2456       reg0       4       yes    yes   none      OVS 1.1+
2457       reg1       4       yes    yes   none      OVS 1.1+
2458       reg2       4       yes    yes   none      OVS 1.1+
2459       reg3       4       yes    yes   none      OVS 1.1+
2460
2461       reg4       4       yes    yes   none      OVS 1.3+
2462       reg5       4       yes    yes   none      OVS 1.7+
2463       reg6       4       yes    yes   none      OVS 1.7+
2464       reg7       4       yes    yes   none      OVS 1.7+
2465       reg8       4       yes    yes   none      OVS 2.6+
2466       reg9       4       yes    yes   none      OVS 2.6+
2467       reg10      4       yes    yes   none      OVS 2.6+
2468       reg11      4       yes    yes   none      OVS 2.6+
2469       reg12      4       yes    yes   none      OVS 2.6+
2470       reg13      4       yes    yes   none      OVS 2.6+
2471
2472       reg14      4       yes    yes   none      OVS 2.6+
2473       reg15      4       yes    yes   none      OVS 2.6+
2474       xreg0      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2475       xreg1      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2476       xreg2      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2477       xreg3      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2478       xreg4      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2479       xreg5      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2480       xreg6      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2481       xreg7      8       yes    yes   none      OF 1.3+ and OVS 2.4+
2482
2483       xxreg0     16      yes    yes   none      OVS 2.6+
2484       xxreg1     16      yes    yes   none      OVS 2.6+
2485       xxreg2     16      yes    yes   none      OVS 2.6+
2486       xxreg3     16      yes    yes   none      OVS 2.6+
2487
2488       These  fields give an OpenFlow switch space for temporary storage while
2489       the pipeline is running. Whereas metadata fields can have a  meaningful
2490       initial  value  and  can  persist  across  some  hops  across  OpenFlow
2491       switches, registers are always initially 0 and their values never  per‐
2492       sist across inter-switch hops (not even across patch ports).
2493
2494       OpenFlow Metadata Field
2495
2496       Name:            metadata
2497       Width:           64 bits
2498       Format:          hexadecimal
2499       Masking:         arbitrary bitwise masks
2500       Prerequisites:   none
2501       Access:          read/write
2502       OpenFlow 1.0:    not supported
2503       OpenFlow 1.1:    yes
2504
2505       OXM:             OXM_OF_METADATA   (2)  since  OpenFlow  1.2  and  Open
2506                        vSwitch 1.8
2507       NXM:             none
2508
2509       This field is the oldest standardized OpenFlow register  field,  intro‐
2510       duced in OpenFlow 1.1. It was introduced to model the limited number of
2511       user-defined bits that some ASIC-based switches can carry through their
2512       pipelines. Because of hardware limitations, OpenFlow allows switches to
2513       support writing and masking only an  implementation-defined  subset  of
2514       bits, even no bits at all. The Open vSwitch software switch always sup‐
2515       ports all 64 bits, but of course an Open vSwitch port to an ASIC  would
2516       have the same restriction as the ASIC itself.
2517
2518       This field has an OXM code point, but OpenFlow 1.4 and earlier allow it
2519       to be modified only with a specialized instruction, not with  a  ``set-
2520       field’’  action.  OpenFlow  1.5  removes this restriction. Open vSwitch
2521       does not enforce this restriction, regardless of OpenFlow version.
2522
2523       Register 0 Field
2524
2525       Name:            reg0
2526
2527       Width:           32 bits
2528       Format:          hexadecimal
2529       Masking:         arbitrary bitwise masks
2530       Prerequisites:   none
2531       Access:          read/write
2532       OpenFlow 1.0:    not supported
2533       OpenFlow 1.1:    not supported
2534       OXM:             none
2535       NXM:             NXM_NX_REG0 (0) since Open vSwitch 1.1
2536
2537       This is the first of several Open vSwitch registers, all of which  have
2538       the same properties. Open vSwitch 1.1 introduced registers 0, 1, 2, and
2539       3, version 1.3 added register 4, version 1.7 added registers 5, 6,  and
2540       7, and version 2.6 added registers 8 through 15.
2541
2542       Extended Register 0 Field
2543
2544       Name:            xreg0
2545       Width:           64 bits
2546       Format:          hexadecimal
2547       Masking:         arbitrary bitwise masks
2548
2549       Prerequisites:   none
2550       Access:          read/write
2551       OpenFlow 1.0:    not supported
2552       OpenFlow 1.1:    not supported
2553       OXM:             OXM_OF_PKT_REG0   (0)  since  OpenFlow  1.3  and  Open
2554                        vSwitch 2.4
2555       NXM:             none
2556
2557       This is the first of the registers introduced in OpenFlow 1.5. OpenFlow
2558       1.5  calls these fields just the ``packet registers,’’ but Open vSwitch
2559       already had 32-bit registers by that name, so  Open  vSwitch  uses  the
2560       name  ``extended  registers’’  in  an  attempt to reduce confusion. The
2561       standard allows for up to 128 registers, each 64 bits  wide,  but  Open
2562       vSwitch  only  implements  4 (in versions 2.4 and 2.5) or 8 (in version
2563       2.6 and later).
2564
2565       Each of the 64-bit extended registers overlays two of the 32-bit regis‐
2566       ters:  xreg0  overlays reg0 and reg1, with reg0 supplying the most-sig‐
2567       nificant bits of xreg0 and reg1 the least-significant. Similarly, xreg1
2568       overlays reg2 and reg3, and so on.
2569
2570       The  OpenFlow specification says, ``In most cases, the packet registers
2571       can not be matched in tables, i.e. they usually can not be used in  the
2572       flow  entry  match  structure’’  [OpenFlow  1.5, section 7.2.3.10], but
2573       there is no reason for a software switch to impose such a  restriction,
2574       and Open vSwitch does not.
2575
2576       Double-Extended Register 0 Field
2577
2578       Name:            xxreg0
2579       Width:           128 bits
2580       Format:          hexadecimal
2581
2582       Masking:         arbitrary bitwise masks
2583       Prerequisites:   none
2584       Access:          read/write
2585       OpenFlow 1.0:    not supported
2586       OpenFlow 1.1:    not supported
2587       OXM:             none
2588       NXM:             NXM_NX_XXREG0 (111) since Open vSwitch 2.6
2589
2590       This  is  the  first of the double-extended registers introduce in Open
2591       vSwitch 2.6. Each of the 128-bit extended registers  overlays  four  of
2592       the 32-bit registers: xxreg0 overlays reg0 through reg3, with reg0 sup‐
2593       plying the most-significant bits of xxreg0 and reg3 the  least-signifi‐
2594       cant. xxreg1 similarly overlays reg4 through reg7, and so on.
2595

LAYER 2 (ETHERNET) FIELDS

2597   Summary:
2598       Name                   Bytes   Mask   RW?   Prereqs    NXM/OXM Support
2599
2600       ─────────────────────  ──────  ─────  ────  ─────────  ─────────────────────
2601       eth_src aka dl_src     6       yes    yes   Ethernet   OF 1.2+ and OVS 1.1+
2602       eth_dst aka dl_dst     6       yes    yes   Ethernet   OF 1.2+ and OVS 1.1+
2603       eth_type aka dl_type   2       no     no    Ethernet   OF 1.2+ and OVS 1.1+
2604
2605       Ethernet  is  the  only layer-2 protocol that Open vSwitch supports. As
2606       with most software, Open vSwitch and OpenFlow regard an Ethernet  frame
2607       to  begin  with  the  14-byte header and end with the final byte of the
2608       payload; that is, the frame check sequence is not  considered  part  of
2609       the frame.
2610
2611       Ethernet Source Field
2612
2613       Name:            eth_src (aka dl_src)
2614
2615       Width:           48 bits
2616       Format:          Ethernet
2617       Masking:         arbitrary bitwise masks
2618       Prerequisites:   Ethernet
2619
2620       Access:          read/write
2621       OpenFlow 1.0:    yes (exact match only)
2622       OpenFlow 1.1:    yes
2623
2624
2625       OXM:             OXM_OF_ETH_SRC (4) since OpenFlow 1.2 and Open vSwitch
2626                        1.7
2627       NXM:             NXM_OF_ETH_SRC (2) since Open vSwitch 1.1
2628
2629       The Ethernet source address:
2630
2631          Ethernet
2632        <---------->
2633        48  48   16
2634       +---+---+----+
2635       |dst|src|type| ...
2636       +---+---+----+
2637
2638
2639       Ethernet Destination Field
2640
2641       Name:            eth_dst (aka dl_dst)
2642       Width:           48 bits
2643       Format:          Ethernet
2644
2645       Masking:         arbitrary bitwise masks
2646       Prerequisites:   Ethernet
2647       Access:          read/write
2648       OpenFlow 1.0:    yes (exact match only)
2649
2650       OpenFlow 1.1:    yes
2651       OXM:             OXM_OF_ETH_DST (3) since OpenFlow 1.2 and Open vSwitch
2652                        1.7
2653       NXM:             NXM_OF_ETH_DST (1) since Open vSwitch 1.1
2654
2655       The Ethernet destination address:
2656
2657          Ethernet
2658        <---------->
2659        48  48   16
2660       +---+---+----+
2661       |dst|src|type| ...
2662       +---+---+----+
2663
2664
2665       Open  vSwitch  1.8  and later support arbitrary masks for source and/or
2666       destination. Earlier versions only support masking the destination with
2667       the following masks:
2668
2669              01:00:00:00:00:00
2670                     Match      only      the     multicast     bit.     Thus,
2671                     dl_dst=01:00:00:00:00:00/01:00:00:00:00:00  matches   all
2672                     multicast  (including  broadcast)  Ethernet  packets, and
2673                     dl_dst=00:00:00:00:00:00/01:00:00:00:00:00  matches   all
2674                     unicast Ethernet packets.
2675
2676              fe:ff:ff:ff:ff:ff
2677                     Match all bits except the multicast bit. This is probably
2678                     not useful.
2679
2680              ff:ff:ff:ff:ff:ff
2681                     Exact match (equivalent to omitting the mask).
2682
2683              00:00:00:00:00:00
2684                     Wildcard all bits (equivalent to dl_dst=*).
2685
2686       Ethernet Type Field
2687
2688       Name:            eth_type (aka dl_type)
2689       Width:           16 bits
2690       Format:          hexadecimal
2691       Masking:         not maskable
2692
2693       Prerequisites:   Ethernet
2694       Access:          read-only
2695       OpenFlow 1.0:    yes (exact match only)
2696       OpenFlow 1.1:    yes (exact match only)
2697       OXM:             OXM_OF_ETH_TYPE  (5)  since  OpenFlow  1.2  and   Open
2698                        vSwitch 1.7
2699
2700       NXM:             NXM_OF_ETH_TYPE (3) since Open vSwitch 1.1
2701
2702       The most commonly seen Ethernet frames today use a format called ``Eth‐
2703       ernet II,’’ in which the last two bytes of the Ethernet header  specify
2704       the  Ethertype. For such a frame, this field is copied from those bytes
2705       of the header, like so:
2706
2707             Ethernet
2708        <---------------->
2709        48  48      16
2710       +---+---+----------+
2711       |dst|src|   type   | ...
2712       +---+---+----------+
2713                ≥0x600
2714
2715
2716       Every Ethernet type has a value 0x600 (1,536) or greater. When the last
2717       two bytes of the Ethernet header have a value too small to be an Ether‐
2718       net type, then the value found there is the total length of  the  frame
2719       in  bytes, excluding the Ethernet header. An 802.2 LLC header typically
2720       follows the Ethernet header. OpenFlow and Open vSwitch only support LLC
2721       headers  with  DSAP and SSAP 0xaa and control byte 0x03, which indicate
2722       that a SNAP header follows the LLC header. In turn, OpenFlow  and  Open
2723       vSwitch  only support a SNAP header with organization 0x000000. In such
2724       a case, this field is copied from the type field in  the  SNAP  header,
2725       like this:
2726
2727           Ethernet           LLC                SNAP
2728        <------------>   <------------>   <----------------->
2729        48  48    16      8    8    8        24        16
2730       +---+---+------+ +----+----+----+ +--------+----------+
2731       |dst|src| type | |DSAP|SSAP|cntl| |  org   |   type   | ...
2732       +---+---+------+ +----+----+----+ +--------+----------+
2733                <0x600   0xaa 0xaa 0x03   0x000000 ≥0x600
2734
2735
2736       When  an 802.1Q header is inserted after the Ethernet source and desti‐
2737       nation, this field is populated with the  encapsulated  Ethertype,  not
2738       the 802.1Q Ethertype. With an Ethernet II inner frame, the result looks
2739       like this:
2740
2741        Ethernet     802.1Q     Ethertype
2742        <------>   <-------->   <-------->
2743         48  48      16   16        16
2744       +----+---+ +------+---+ +----------+
2745       |dst |src| | TPID |TCI| |   type   | ...
2746       +----+---+ +------+---+ +----------+
2747                   0x8100       ≥0x600
2748
2749
2750       LLC and SNAP encapsulation look like this with an 802.1Q header:
2751
2752        Ethernet     802.1Q     Ethertype        LLC                SNAP
2753        <------>   <-------->   <------->   <------------>   <----------------->
2754         48  48      16   16       16        8    8    8        24        16
2755       +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2756       |dst |src| | TPID |TCI| |  type   | |DSAP|SSAP|cntl| |  org   |   type   | ...
2757       +----+---+ +------+---+ +---------+ +----+----+----+ +--------+----------+
2758                   0x8100        <0x600     0xaa 0xaa 0x03   0x000000 ≥0x600
2759
2760
2761       When a packet doesn’t match any of the header formats described  above,
2762       Open    vSwitch    and    OpenFlow    set    this    field   to   0x5ff
2763       (OFP_DL_TYPE_NOT_ETH_TYPE).
2764

VLAN FIELDS

2766   Summary:
2767       Name          Bytes             Mask   RW?   Prereqs    NXM/OXM Support
2768
2769       ────────────  ────────────────  ─────  ────  ─────────  ─────────────────────
2770       dl_vlan       2 (low 12 bits)   no     yes   Ethernet
2771       dl_vlan_pcp   1 (low 3 bits)    no     yes   Ethernet
2772
2773       vlan_vid      2 (low 12 bits)   yes    yes   Ethernet   OF 1.2+ and OVS 1.7+
2774       vlan_pcp      1 (low 3 bits)    no     yes   VLAN VID   OF 1.2+ and OVS 1.7+
2775       vlan_tci      2                 yes    yes   Ethernet   OVS 1.1+
2776
2777       The 802.1Q VLAN header causes more trouble than any other  4  bytes  in
2778       networking.  OpenFlow  1.0,  1.1, and 1.2+ all treat VLANs differently.
2779       Open vSwitch extensions add another variant to the  mix.  Open  vSwitch
2780       reconciles all four treatments as best it can.
2781
2782   VLAN Header Format
2783       An 802.1Q VLAN header consists of two 16-bit fields:
2784
2785          TPID        TCI
2786        <-------> <--------->
2787           16      3   1  12
2788       +---------+---+---+---+
2789       |Ethertype|PCP|CFI|VID|
2790       +---------+---+---+---+
2791         0x8100        0
2792
2793
2794       The  first  16  bits of the VLAN header, the TPID (Tag Protocol IDenti‐
2795       fier), is an Ethertype. When the VLAN header is inserted just after the
2796       source  and  destination  MAC  addresses in a Ethertype frame, the TPID
2797       serves to identify the presence of the VLAN.  The  standard  TPID,  the
2798       only one that Open vSwitch supports, is 0x8100. OpenFlow 1.0 explicitly
2799       supports only TPID 0x8100. OpenFlow 1.1, but not earlier or later  ver‐
2800       sions,  also  requires  support  for TPID 0x88a8 (Open vSwitch does not
2801       support this). OpenFlow 1.2 through 1.5 do not require support for spe‐
2802       cific  TPIDs (the ``push vlan header’’ action does say that only 0x8100
2803       and 0x88a8 should be pushed). No version of OpenFlow provides a way  to
2804       distinguish or match on the TPID.
2805
2806       The remaining 16 bits of the VLAN header, the TCI (Tag Control Informa‐
2807       tion), is subdivided into three subfields:
2808
2809              ·      PCP (Priority Control Point), is a 3-bit 802.1p priority.
2810                     The  lowest  priority  is  value  1, the second-lowest is
2811                     value 0, and priority increases from 2 up to highest pri‐
2812                     ority 7.
2813
2814              ·      CFI (Canonical Format Indicator), is a 1-bit field. On an
2815                     Ethernet network, its value is always 0. This led  to  it
2816                     later being repurposed under the name DEI (Drop Eligibil‐
2817                     ity Indicator). By either name, OpenFlow and Open vSwitch
2818                     don’t provide any way to match or set this bit.
2819
2820              ·      VID (VLAN IDentifier), is a 12-bit VLAN. If the VID is 0,
2821                     then the frame is not part of a VLAN. In that  case,  the
2822                     VLAN  header  is called a priority tag because it is only
2823                     meaningful for assigning the frame a priority. VID  0xfff
2824                     (4,095) is reserved.
2825
2826       See eth_type for illustrations of a complete Ethernet frame with 802.1Q
2827       tag included.
2828
2829   Multiple VLANs
2830       Open vSwitch can match only a single VLAN header. If more than one VLAN
2831       header  is  present,  then  eth_type  holds  the TPID of the inner VLAN
2832       header. Open vSwitch stops parsing the packet after the inner TPID,  so
2833       matching  further  into the packet (e.g. on the inner TCI or L3 fields)
2834       is not possible.
2835
2836       OpenFlow only directly supports matching a single VLAN header. In Open‐
2837       Flow  1.1  or later, one OpenFlow table can match on the outermost VLAN
2838       header and pop it off, and a later OpenFlow table can match on the next
2839       outermost header. Open vSwitch does not support this.
2840
2841   VLAN Field Details
2842       The  four variants have three different levels of expressiveness: Open‐
2843       Flow 1.0 and 1.1 VLAN matching are less  powerful  than  OpenFlow  1.2+
2844       VLAN  matching, which is less powerful than Open vSwitch extension VLAN
2845       matching.
2846
2847   OpenFlow 1.0 VLAN Fields
2848       OpenFlow 1.0 uses two fields, called dl_vlan and dl_vlan_pcp,  each  of
2849       which  can  be  either  exact-matched  or  wildcarded,  to specify VLAN
2850       matches:
2851
2852              ·      When both dl_vlan and  dl_vlan_pcp  are  wildcarded,  the
2853                     flow matches packets without an 802.1Q header or with any
2854                     802.1Q header.
2855
2856              ·      The match dl_vlan=0xffff causes  a  flow  to  match  only
2857                     packets without an 802.1Q header. Such a flow should also
2858                     wildcard dl_vlan_pcp, since a packet  without  an  802.1Q
2859                     header  does  not  have  a PCP. OpenFlow does not specify
2860                     what to do if a match on PCP  is  actually  present,  but
2861                     Open vSwitch ignores it.
2862
2863              ·      Otherwise,  the  flow matches only packets with an 802.1Q
2864                     header. If dl_vlan is not wildcarded, then the flow  only
2865                     matches  packets  with the VLAN ID specified in dl_vlan’s
2866                     low 12 bits. If dl_vlan_pcp is not wildcarded,  then  the
2867                     flow  only matches packets with the priority specified in
2868                     dl_vlan_pcp’s low 3 bits.
2869
2870                     OpenFlow does not specify how to  interpret  the  high  4
2871                     bits  of  dl_vlan or the high 5 bits of dl_vlan_pcp. Open
2872                     vSwitch ignores them.
2873
2874   OpenFlow 1.1 VLAN Fields
2875       VLAN matching in OpenFlow 1.1 is  similar  to  OpenFlow  1.0.  The  one
2876       refinement  is  that  when  dl_vlan matches on 0xfffe (OFVPID_ANY), the
2877       flow matches only packets with an 802.1Q header, with any VLAN  ID.  If
2878       dl_vlan_pcp  is  wildcarded, the flow matches any packet with an 802.1Q
2879       header, regardless of VLAN ID or priority. If dl_vlan_pcp is not  wild‐
2880       carded,  then the flow only matches packets with the priority specified
2881       in dl_vlan_pcp’s low 3 bits.
2882
2883       OpenFlow 1.1 uses the name OFPVID_NONE, instead of OFP_VLAN_NONE, for a
2884       dl_vlan of 0xffff, but it has the same meaning.
2885
2886       In  OpenFlow  1.1,  Open  vSwitch reports error OFPBMC_BAD_VALUE for an
2887       attempt to match on dl_vlan between 4,096  and  0xfffd,  inclusive,  or
2888       dl_vlan_pcp greater than 7.
2889
2890   OpenFlow 1.2 VLAN Fields
2891       OpenFlow 1.2+ VLAN ID Field
2892
2893       Name:            vlan_vid
2894       Width:           16 bits (only the least-significant 12 bits may be nonzero)
2895       Format:          decimal
2896       Masking:         arbitrary bitwise masks
2897       Prerequisites:   Ethernet
2898       Access:          read/write
2899
2900       OpenFlow 1.0:    yes (exact match only)
2901       OpenFlow 1.1:    yes (exact match only)
2902       OXM:             OXM_OF_VLAN_VID (6) since OpenFlow 1.2 and Open vSwitch 1.7
2903       NXM:             none
2904
2905       The  OpenFlow  standard  describes this field as consisting of ``12+1’’
2906       bits. On ingress, its value is 0 if no 802.1Q header  is  present,  and
2907       otherwise  it holds the VLAN VID in its least significant 12 bits, with
2908       bit 12 (0x1000 aka OFPVID_PRESENT) also set to 1. The three  most  sig‐
2909       nificant bits are always zero:
2910
2911        OXM_OF_VLAN_VID
2912        <------------->
2913         3  1     12
2914       +---+--+--------+
2915       |   |P |VLAN ID |
2916       +---+--+--------+
2917         0
2918
2919
2920       As  a  consequence  of this field’s format, one may use it to match the
2921       VLAN ID in all of the ways available with the OpenFlow 1.0 and 1.1 for‐
2922       mats, and a few new ways:
2923
2924              Fully wildcarded
2925                     Matches any packet, that is, one without an 802.1Q header
2926                     or with an 802.1Q header with any TCI value.
2927
2928              Value 0x0000 (OFPVID_NONE), mask 0xffff (or no mask)
2929                     Matches only packets without an 802.1Q header.
2930
2931              Value 0x1000, mask 0x1000
2932                     Matches any packet with an 802.1Q header,  regardless  of
2933                     VLAN ID.
2934
2935              Value 0x1009, mask 0xffff (or no mask)
2936                     Match only packets with an 802.1Q header with VLAN ID 9.
2937
2938              Value 0x1001, mask 0x1001
2939                     Matches  only  packets that have an 802.1Q header with an
2940                     odd-numbered VLAN ID. (This is just an example;  one  can
2941                     match on any desired VLAN ID bit pattern.)
2942
2943       OpenFlow 1.2+ VLAN Priority Field
2944
2945       Name:            vlan_pcp
2946       Width:           8 bits (only the least-significant 3 bits may be nonzero)
2947       Format:          decimal
2948
2949       Masking:         not maskable
2950       Prerequisites:   VLAN VID
2951       Access:          read/write
2952       OpenFlow 1.0:    yes (exact match only)
2953       OpenFlow 1.1:    yes (exact match only)
2954
2955
2956       OXM:             OXM_OF_VLAN_PCP  (7)  since OpenFlow 1.2 and Open vSwitch
2957                        1.7
2958       NXM:             none
2959
2960       The 3 least significant bits may be used to match the PCP  bits  in  an
2961       802.1Q header. Other bits are always zero:
2962
2963        OXM_OF_VLAN_VID
2964        <------------->
2965           5       3
2966       +--------+------+
2967       |  zero  | PCP  |
2968       +--------+------+
2969           0
2970
2971
2972       This  field  may  only be used when vlan_vid is not wildcarded and does
2973       not exact match on 0 (which  only  matches  when  there  is  no  802.1Q
2974       header).
2975
2976       See VLAN Comparison Chart, below, for some examples.
2977
2978   Open vSwitch Extension VLAN Field
2979       The vlan_tci extension can describe more kinds of VLAN matches than the
2980       other variants. It is also simpler than the other variants.
2981
2982       VLAN TCI Field
2983
2984       Name:            vlan_tci
2985       Width:           16 bits
2986       Format:          hexadecimal
2987       Masking:         arbitrary bitwise masks
2988       Prerequisites:   Ethernet
2989       Access:          read/write
2990
2991       OpenFlow 1.0:    yes (exact match only)
2992       OpenFlow 1.1:    yes (exact match only)
2993       OXM:             none
2994       NXM:             NXM_OF_VLAN_TCI (4) since Open vSwitch 1.1
2995
2996       For a packet without an 802.1Q header, this field is zero. For a packet
2997       with  an  802.1Q  header,  this  field is the TCI with the bit in CFI’s
2998       position (marked P for ``present’’ below) forced  to  1.  Thus,  for  a
2999       packet in VLAN 9 with priority 7, it has the value 0xf009:
3000
3001        NXM_VLAN_TCI
3002        <---------->
3003         3   1   12
3004       +----+--+----+
3005       |PCP |P |VID |
3006       +----+--+----+
3007         7   1   9
3008
3009
3010       Usage examples:
3011
3012              vlan_tci=0
3013                     Match packets without an 802.1Q header.
3014
3015              vlan_tci=0x1000/0x1000
3016                     Match  packets  with an 802.1Q header, regardless of VLAN
3017                     and priority values.
3018
3019              vlan_tci=0xf123
3020                     Match packets tagged with priority 7 in VLAN 0x123.
3021
3022              vlan_tci=0x1123/0x1fff
3023                     Match packets tagged with VLAN 0x123 (and any priority).
3024
3025              vlan_tci=0x5000/0xf000
3026                     Match packets tagged with priority 2 (in any VLAN).
3027
3028              vlan_tci=0/0xfff
3029                     Match packets with no 802.1Q header or tagged with VLAN 0
3030                     (and any priority).
3031
3032              vlan_tci=0x5000/0xe000
3033                     Match packets with no 802.1Q header or tagged with prior‐
3034                     ity 2 (in any VLAN).
3035
3036              vlan_tci=0/0xefff
3037                     Match packets with no 802.1Q header or tagged with VLAN 0
3038                     and priority 0.
3039
3040       See VLAN Comparison Chart, below, for more examples.
3041
3042   VLAN Comparison Chart
3043       The  following table describes each of several possible matching crite‐
3044       ria on 802.1Q header may be expressed with each variation of  the  VLAN
3045       matching fields:
3046
3047       Criteria        OpenFlow 1.0    OpenFlow 1.1    OpenFlow 1.2+   NXM
3048                                             _      _      _      _      _
3049
3050           [1]     ????/1,??/?     ????/1,??/?     0000/0000,--  0000/0000
3051           [2]     ffff/0,??/?     ffff/0,??/?     0000/ffff,--  0000/ffff
3052           [3]     0xxx/0,??/1     0xxx/0,??/1     1xxx/ffff,--  1xxx/1fff
3053           [4]     ????/1,0y/0     fffe/0,0y/0     1000/1000,0y  z000/f000
3054           [5]     0xxx/0,0y/0     0xxx/0,0y/0     1xxx/ffff,0y  zxxx/ffff
3055                           [6]     (none)  (none)  1001/1001,--  1001/1001
3056                                 [7]     (none)  (none)  (none)  3000/3000
3057                                 [8]     (none)  (none)  (none)  0000/0fff
3058                                 [9]     (none)  (none)  (none)  0000/f000
3059                                 [10]    (none)  (none)  (none)  0000/efff
3060
3061       All  numbers  in the table are expressed in hexadecimal. The columns in
3062       the table are interpreted as follows:
3063
3064              Criteria
3065                     See the list below.
3066
3067              OpenFlow 1.0
3068              OpenFlow 1.1
3069                   wwww/x,yy/z means VLAN ID match value  wwww  with  wildcard
3070                   bit  x  and  VLAN PCP match value yy with wildcard bit z. ?
3071                   means that the given bits are ignored (and conventionally 0
3072                   for  wwww  or  yy, conventionally 1 for x or z). ``(none)’’
3073                   means that OpenFlow 1.0 (or 1.1) cannot  match  with  these
3074                   criteria.
3075
3076              OpenFlow 1.2+
3077                   xxxx/yyyy,zz  means vlan_vid with value xxxx and mask yyyy,
3078                   and vlan_pcp (which is not  maskable)  with  value  zz.  --
3079                   means that vlan_pcp is omitted. ``(none)’’ means that Open‐
3080                   Flow 1.2 cannot match with these criteria.
3081
3082              NXM  xxxx/yyyy means vlan_tci with value xxxx and mask yyyy.
3083
3084       The matching criteria described by the table are:
3085
3086              [1]    Matches any packet, that is, one without an 802.1Q header
3087                     or with an 802.1Q header with any TCI value.
3088
3089              [2]    Matches only packets without an 802.1Q header.
3090
3091                     OpenFlow  1.0  doesn’t  define the behavior if dl_vlan is
3092                     set to 0xffff and dl_vlan_pcp is  not  wildcarded.  (Open
3093                     vSwitch always ignores dl_vlan_pcp when dl_vlan is set to
3094                     0xffff.)
3095
3096                     OpenFlow 1.1 says explicitly to ignore  dl_vlan_pcp  when
3097                     dl_vlan is set to 0xffff.
3098
3099                     OpenFlow  1.2  doesn’t  say how to interpret a match with
3100                     vlan_vid value 0 and a mask with OFPVID_PRESENT  (0x1000)
3101                     set  to  1 and some other bits in the mask set to 1 also.
3102                     Open vSwitch interprets it the same  way  as  a  mask  of
3103                     0x1000.
3104
3105                     Any  NXM  match with vlan_tci value 0 and the CFI bit set
3106                     to 1 in the mask is equivalent to the one listed  in  the
3107                     table.
3108
3109              [3]    Matches  only packets that have an 802.1Q header with VID
3110                     xxx (and any PCP).
3111
3112              [4]    Matches only packets that have an 802.1Q header with  PCP
3113                     y (and any VID).
3114
3115                     OpenFlow 1.0 doesn’t clearly define the behavior for this
3116                     case. Open vSwitch implements it this way.
3117
3118                     In the NXM value, z equals (y << 1) | 1.
3119
3120              [5]    Matches only packets that have an 802.1Q header with  VID
3121                     xxx and PCP y.
3122
3123                     In the NXM value, z equals (y << 1) | 1.
3124
3125              [6]    Matches  only  packets that have an 802.1Q header with an
3126                     odd-numbered VID (and any PCP). Only possible with  Open‐
3127                     Flow 1.2 and NXM. (This is just an example; one can match
3128                     on any desired VID bit pattern.)
3129
3130              [7]    Matches only packets that have an 802.1Q header  with  an
3131                     odd-numbered  PCP  (and any VID). Only possible with NXM.
3132                     (This is just an example; one can match  on  any  desired
3133                     VID bit pattern.)
3134
3135              [8]    Matches  packets  with no 802.1Q header or with an 802.1Q
3136                     header with a VID of 0. Only possible with NXM.
3137
3138              [9]    Matches packets with no 802.1Q header or with  an  802.1Q
3139                     header with a PCP of 0. Only possible with NXM.
3140
3141              [10]   Matches  packets  with no 802.1Q header or with an 802.1Q
3142                     header with both VID and PCP of  0.  Only  possible  with
3143                     NXM.

LAYER 2.5: MPLS FIELDS

3145   Summary:
3146       Name         Bytes             Mask   RW?   Prereqs   NXM/OXM Support
3147
3148       ───────────  ────────────────  ─────  ────  ────────  ──────────────────────
3149       mpls_label   4 (low 20 bits)   no     yes   MPLS      OF 1.2+ and OVS 1.11+
3150       mpls_tc      1 (low 3 bits)    no     yes   MPLS      OF 1.2+ and OVS 1.11+
3151
3152       mpls_bos     1 (low 1 bits)    no     no    MPLS      OF 1.3+ and OVS 1.11+
3153       mpls_ttl     1                 no     yes   MPLS      OVS 2.6+
3154
3155       One  or  more MPLS headers (more commonly called MPLS labels) follow an
3156       Ethernet type field that specifies an MPLS Ethernet  type  [RFC  3032].
3157       Ethertype  0x8847  is  used  for all unicast. Multicast MPLS is divided
3158       into two specific classes, one of which uses Ethertype 0x8847  and  the
3159       other 0x8848 [RFC 5332].
3160
3161       The most common overall packet format is Ethernet II, shown below (SNAP
3162       encapsulation may be used but is not ordinarily seen in  Ethernet  net‐
3163       works):
3164
3165           Ethernet           MPLS
3166        <------------>   <------------>
3167        48  48    16      20   3  1  8
3168       +---+---+------+ +-----+--+-+---+
3169       |dst|src| type | |label|TC|S|TTL| ...
3170       +---+---+------+ +-----+--+-+---+
3171                0x8847
3172
3173
3174       MPLS  can  be  encapsulated  inside an 802.1Q header, in which case the
3175       combination looks like this:
3176
3177        Ethernet     802.1Q     Ethertype        MPLS
3178        <------>   <-------->   <------->   <------------>
3179         48  48      16   16       16        20   3  1  8
3180       +----+---+ +------+---+ +---------+ +-----+--+-+---+
3181       |dst |src| | TPID |TCI| |  type   | |label|TC|S|TTL| ...
3182       +----+---+ +------+---+ +---------+ +-----+--+-+---+
3183                   0x8100        0x8847
3184
3185
3186       The fields within an MPLS label are:
3187
3188              Label, 20 bits.
3189                     An identifier.
3190
3191              Traffic control (TC), 3 bits.
3192                     Used for quality of service.
3193
3194              Bottom of stack (BOS), 1 bit (labeled just ``S’’ above).
3195                     0 indicates that another MPLS label follows this one.
3196
3197                     1 indicates that this MPLS label is the last one  in  the
3198                     stack, so that some other protocol follows this one.
3199
3200              Time to live (TTL), 8 bits.
3201                     Each  hop across an MPLS network decrements the TTL by 1.
3202                     If it reaches 0, the packet is discarded.
3203
3204                     OpenFlow does not make the MPLS TTL available as a  match
3205                     field, but actions are available to set and decrement the
3206                     TTL. Open vSwitch 2.6 and later makes the MPLS TTL avail‐
3207                     able as an extension.
3208
3209   MPLS Label Stacks
3210       Unlike the other encapsulations supported by OpenFlow and Open vSwitch,
3211       MPLS labels are routinely used in ``stacks’’  two  or  three  deep  and
3212       sometimes  even  deeper.  Open  vSwitch  currently supports up to three
3213       labels.
3214
3215       The OpenFlow specification only supports matching on the outermost MPLS
3216       label  at  any given time. To match on the second label, one must first
3217       ``pop’’ the outer label and advance to another  OpenFlow  table,  where
3218       the  inner  label may be matched. To match on the third label, one must
3219       pop the two outer labels, and so on.
3220
3221   MPLS Inner Protocol
3222       Unlike all other forms of encapsulation that Open vSwitch and  OpenFlow
3223       support,  an MPLS label does not indicate what inner protocol it encap‐
3224       sulates. Different deployments determine the inner protocol in  differ‐
3225       ent ways [RFC 3032]:
3226
3227              ·      A  few  reserved label values do indicate an inner proto‐
3228                     col. Label 0, the ``IPv4 Explicit NULL Label,’’ indicates
3229                     inner  IPv4.  Label  2, the ``IPv6 Explicit NULL Label,’’
3230                     indicates inner IPv6.
3231
3232              ·      Some deployments use  a  single  inner  protocol  consis‐
3233                     tently.
3234
3235              ·      In  some deployments, the inner protocol must be inferred
3236                     from the innermost label.
3237
3238              ·      In some deployments, the inner protocol must be  inferred
3239                     from  the innermost label and the encapsulated data, e.g.
3240                     to distinguish between  inner  IPv4  and  IPv6  based  on
3241                     whether the first nibble of the inner protocol data are 4
3242                     or 6. OpenFlow and Open vSwitch do not currently  support
3243                     these cases.
3244
3245       Open  vSwitch  and  OpenFlow  do  not infer the inner protocol, even if
3246       reserved label values are in use. Instead, the flow table must  specify
3247       the inner protocol at the time it pops the bottommost MPLS label, using
3248       the Ethertype argument to the pop_mpls action.
3249
3250   Field Details
3251       MPLS Label Field
3252
3253       Name:            mpls_label
3254       Width:           32 bits (only the least-significant 20 bits may be nonzero)
3255       Format:          decimal
3256       Masking:         not maskable
3257       Prerequisites:   MPLS
3258       Access:          read/write
3259       OpenFlow 1.0:    not supported
3260       OpenFlow 1.1:    yes (exact match only)
3261
3262       OXM:             OXM_OF_MPLS_LABEL (34) since OpenFlow 1.2 and Open  vSwitch
3263                        1.11
3264       NXM:             none
3265
3266       The  least  significant  20 bits hold the ``label’’ field from the MPLS
3267       label. Other bits are zero:
3268
3269        OXM_OF_MPLS_LABEL
3270        <--------------->
3271           12       20
3272       +--------+--------+
3273       |  zero  | label  |
3274       +--------+--------+
3275           0
3276
3277
3278       Most label values are available for  any  use  by  deployments.  Values
3279       under 16 are reserved.
3280
3281       MPLS Traffic Class Field
3282
3283       Name:            mpls_tc
3284       Width:           8 bits (only the least-significant 3 bits may be nonzero)
3285       Format:          decimal
3286       Masking:         not maskable
3287       Prerequisites:   MPLS
3288
3289       Access:          read/write
3290       OpenFlow 1.0:    not supported
3291       OpenFlow 1.1:    yes (exact match only)
3292       OXM:             OXM_OF_MPLS_TC  (35)  since OpenFlow 1.2 and Open vSwitch
3293                        1.11
3294       NXM:             none
3295
3296       The least significant 3 bits hold the TC field  from  the  MPLS  label.
3297       Other bits are zero:
3298
3299        OXM_OF_MPLS_TC
3300        <------------>
3301           5       3
3302       +--------+-----+
3303       |  zero  | TC  |
3304       +--------+-----+
3305           0
3306
3307
3308       This  field  is  intended  for  use  for  Quality  of Service (QoS) and
3309       Explicit Congestion Notification purposes, but its particular interpre‐
3310       tation is deployment specific.
3311
3312       Before 2009, this field was named EXP and reserved for experimental use
3313       [RFC 5462].
3314
3315       MPLS Bottom of Stack Field
3316
3317       Name:            mpls_bos
3318       Width:           8 bits (only the least-significant 1 bits may be nonzero)
3319       Format:          decimal
3320       Masking:         not maskable
3321       Prerequisites:   MPLS
3322       Access:          read-only
3323       OpenFlow 1.0:    not supported
3324
3325       OpenFlow 1.1:    not supported
3326       OXM:             OXM_OF_MPLS_BOS (36) since OpenFlow 1.3 and Open  vSwitch
3327                        1.11
3328       NXM:             none
3329
3330       The  least  significant  bit  holds  the BOS field from the MPLS label.
3331       Other bits are zero:
3332
3333        OXM_OF_MPLS_BOS
3334        <------------->
3335           7       1
3336       +--------+------+
3337       |  zero  | BOS  |
3338       +--------+------+
3339           0
3340
3341
3342       This field is useful as part of processing a series  of  incoming  MPLS
3343       labels.  A  flow that includes a pop_mpls action should generally match
3344       on mpls_bos:
3345
3346              ·      When mpls_bos is 1, there is another MPLS label following
3347                     this  one,  so the Ethertype passed to pop_mpls should be
3348                     an MPLS Ethertype. For example: table=0,  dl_type=0x8847,
3349                     mpls_bos=1, actions=pop_mpls:0x8847, goto_table:1
3350
3351              ·      When  mpls_bos  is 0, this MPLS label is the last one, so
3352                     the Ethertype passed to pop_mpls  should  be  a  non-MPLS
3353                     Ethertype   such   as   IPv4.   For   example:   table=1,
3354                     dl_type=0x8847,   mpls_bos=0,    actions=pop_mpls:0x0800,
3355                     goto_table:2
3356
3357       MPLS Time-to-Live Field
3358
3359       Name:            mpls_ttl
3360       Width:           8 bits
3361       Format:          decimal
3362
3363       Masking:         not maskable
3364       Prerequisites:   MPLS
3365       Access:          read/write
3366       OpenFlow 1.0:    not supported
3367       OpenFlow 1.1:    not supported
3368       OXM:             none
3369       NXM:             NXM_NX_MPLS_TTL (30) since Open vSwitch 2.6
3370
3371       Holds the 8-bit time-to-live field from the MPLS label:
3372
3373        NXM_NX_MPLS_TTL
3374        <------------->
3375               8
3376       +---------------+
3377       |      TTL      |
3378       +---------------+
3379
3380

LAYER 3: IPV4 AND IPV6 FIELDS

3382   Summary:
3383       Name                    Bytes             Mask   RW?   Prereqs     NXM/OXM Support
3384       ──────────────────────  ────────────────  ─────  ────  ──────────  ─────────────────────
3385       ip_src aka nw_src       4                 yes    yes   IPv4        OF 1.2+ and OVS 1.1+
3386
3387       ip_dst aka nw_dst       4                 yes    yes   IPv4        OF 1.2+ and OVS 1.1+
3388       ipv6_src                16                yes    yes   IPv6        OF 1.2+ and OVS 1.1+
3389       ipv6_dst                16                yes    yes   IPv6        OF 1.2+ and OVS 1.1+
3390       ipv6_label              4 (low 20 bits)   yes    yes   IPv6        OF 1.2+ and OVS 1.4+
3391       nw_proto aka ip_proto   1                 no     no    IPv4/IPv6   OF 1.2+ and OVS 1.1+
3392       nw_ttl                  1                 no     yes   IPv4/IPv6   OVS 1.4+
3393
3394       ip_frag aka nw_frag     1 (low 2 bits)    yes    no    IPv4/IPv6   OVS 1.3+
3395       nw_tos                  1                 no     yes   IPv4/IPv6   OVS 1.1+
3396       ip_dscp                 1 (low 6 bits)    no     yes   IPv4/IPv6   OF 1.2+ and OVS 1.7+
3397       nw_ecn aka ip_ecn       1 (low 2 bits)    no     yes   IPv4/IPv6   OF 1.2+ and OVS 1.4+
3398
3399   IPv4 Specific Fields
3400       These  fields  are  applicable  only to IPv4 flows, that is, flows that
3401       match on the IPv4 Ethertype 0x0800.
3402
3403       IPv4 Source Address Field
3404
3405       Name:            ip_src (aka nw_src)
3406       Width:           32 bits
3407       Format:          IPv4
3408       Masking:         arbitrary bitwise masks
3409
3410       Prerequisites:   IPv4
3411       Access:          read/write
3412       OpenFlow 1.0:    yes (CIDR match only)
3413       OpenFlow 1.1:    yes
3414       OXM:             OXM_OF_IPV4_SRC  (11)  since  OpenFlow  1.2  and  Open
3415                        vSwitch 1.7
3416       NXM:             NXM_OF_IP_SRC (7) since Open vSwitch 1.1
3417
3418       The source address from the IPv4 header:
3419
3420          Ethernet            IPv4
3421        <----------->   <--------------->
3422        48  48   16           8   32  32
3423       +---+---+-----+ +---+-----+---+---+
3424       |dst|src|type | |...|proto|src|dst| ...
3425       +---+---+-----+ +---+-----+---+---+
3426                0x800
3427
3428
3429       For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3430       matches on nw_src as actually referring to the ARP SPA.
3431
3432       IPv4 Destination Address Field
3433
3434       Name:            ip_dst (aka nw_dst)
3435       Width:           32 bits
3436       Format:          IPv4
3437       Masking:         arbitrary bitwise masks
3438       Prerequisites:   IPv4
3439       Access:          read/write
3440       OpenFlow 1.0:    yes (CIDR match only)
3441
3442       OpenFlow 1.1:    yes
3443       OXM:             OXM_OF_IPV4_DST  (12)  since  OpenFlow  1.2  and  Open
3444                        vSwitch 1.7
3445       NXM:             NXM_OF_IP_DST (8) since Open vSwitch 1.1
3446
3447       The destination address from the IPv4 header:
3448
3449          Ethernet            IPv4
3450        <----------->   <--------------->
3451        48  48   16           8   32  32
3452       +---+---+-----+ +---+-----+---+---+
3453       |dst|src|type | |...|proto|src|dst| ...
3454       +---+---+-----+ +---+-----+---+---+
3455                0x800
3456
3457
3458       For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3459       matches on nw_dst as actually referring to the ARP TPA.
3460
3461   IPv6 Specific Fields
3462       These fields apply only to IPv6 flows, that is, flows that match on the
3463       IPv6 Ethertype 0x86dd.
3464
3465       IPv6 Source Address Field
3466
3467       Name:            ipv6_src
3468       Width:           128 bits
3469       Format:          IPv6
3470       Masking:         arbitrary bitwise masks
3471       Prerequisites:   IPv6
3472       Access:          read/write
3473
3474       OpenFlow 1.0:    not supported
3475       OpenFlow 1.1:    not supported
3476       OXM:             OXM_OF_IPV6_SRC  (26)  since  OpenFlow  1.2  and  Open
3477                        vSwitch 1.1
3478       NXM:             NXM_NX_IPV6_SRC (19) since Open vSwitch 1.1
3479
3480       The source address from the IPv6 header:
3481
3482           Ethernet            IPv6
3483        <------------>   <-------------->
3484        48  48    16          8   128 128
3485       +---+---+------+ +---+----+---+---+
3486       |dst|src| type | |...|next|src|dst| ...
3487       +---+---+------+ +---+----+---+---+
3488                0x86dd
3489
3490
3491       Open vSwitch 1.8 added support for bitwise matching;  earlier  versions
3492       supported only CIDR masks.
3493
3494       IPv6 Destination Address Field
3495
3496       Name:            ipv6_dst
3497
3498       Width:           128 bits
3499       Format:          IPv6
3500       Masking:         arbitrary bitwise masks
3501       Prerequisites:   IPv6
3502       Access:          read/write
3503       OpenFlow 1.0:    not supported
3504       OpenFlow 1.1:    not supported
3505
3506       OXM:             OXM_OF_IPV6_DST  (27)  since  OpenFlow  1.2  and  Open
3507                        vSwitch 1.1
3508       NXM:             NXM_NX_IPV6_DST (20) since Open vSwitch 1.1
3509
3510       The destination address from the IPv6 header:
3511
3512           Ethernet            IPv6
3513        <------------>   <-------------->
3514        48  48    16          8   128 128
3515       +---+---+------+ +---+----+---+---+
3516       |dst|src| type | |...|next|src|dst| ...
3517       +---+---+------+ +---+----+---+---+
3518                0x86dd
3519
3520
3521       Open vSwitch 1.8 added support for bitwise matching;  earlier  versions
3522       supported only CIDR masks.
3523
3524       IPv6 Flow Label Field
3525
3526       Name:            ipv6_label
3527       Width:           32 bits (only the least-significant 20 bits may be nonzero)
3528       Format:          hexadecimal
3529
3530       Masking:         arbitrary bitwise masks
3531       Prerequisites:   IPv6
3532       Access:          read/write
3533       OpenFlow 1.0:    not supported
3534       OpenFlow 1.1:    not supported
3535       OXM:             OXM_OF_IPV6_FLABEL (28) since OpenFlow 1.2 and Open vSwitch
3536                        1.7
3537
3538       NXM:             NXM_NX_IPV6_LABEL (27) since Open vSwitch 1.4
3539
3540       The least significant 20 bits hold the flow label field from  the  IPv6
3541       header. Other bits are zero:
3542
3543        OXM_OF_IPV6_FLABEL
3544        <---------------->
3545           12       20
3546       +--------+---------+
3547       |  zero  |  label  |
3548       +--------+---------+
3549           0
3550
3551
3552   IPv4/IPv6 Fields
3553       These fields exist with at least approximately the same meaning in both
3554       IPv4 and IPv6, so they are treated as a single field for matching  pur‐
3555       poses.  Any  flow that matches on the IPv4 Ethertype 0x0800 or the IPv6
3556       Ethertype 0x86dd may match on these fields.
3557
3558       IPv4/v6 Protocol Field
3559
3560       Name:            nw_proto (aka ip_proto)
3561       Width:           8 bits
3562       Format:          decimal
3563
3564       Masking:         not maskable
3565       Prerequisites:   IPv4/IPv6
3566       Access:          read-only
3567       OpenFlow 1.0:    yes (exact match only)
3568       OpenFlow 1.1:    yes (exact match only)
3569       OXM:             OXM_OF_IP_PROTO  (10)  since  OpenFlow  1.2  and  Open
3570                        vSwitch 1.7
3571       NXM:             NXM_OF_IP_PROTO (6) since Open vSwitch 1.1
3572
3573       Matches the IPv4 or IPv6 protocol type.
3574
3575       For historical reasons, in an ARP or RARP flow, Open vSwitch interprets
3576       matches on nw_proto as actually referring to the ARP  opcode.  The  ARP
3577       opcode  is a 16-bit field, so for matching purposes ARP opcodes greater
3578       than 255 are treated as 0; this works adequately  because  in  practice
3579       ARP and RARP only use opcodes 1 through 4.
3580
3581       IPv4/v6 TTL/Hop Limit Field
3582
3583       Name:            nw_ttl
3584       Width:           8 bits
3585       Format:          decimal
3586       Masking:         not maskable
3587       Prerequisites:   IPv4/IPv6
3588       Access:          read/write
3589       OpenFlow 1.0:    not supported
3590
3591       OpenFlow 1.1:    not supported
3592       OXM:             none
3593       NXM:             NXM_NX_IP_TTL (29) since Open vSwitch 1.4
3594
3595       The  main  reason  to  match on the TTL or hop limit field is to detect
3596       whether a dec_ttl action will fail due to a TTL exceeded error. Another
3597       way  that  a  controller  can  detect  TTL  exceeded  is  to listen for
3598       OFPR_INVALID_TTL ``packet-in’’ messages via OpenFlow.
3599
3600       IPv4/v6 Fragment Bitmask Field
3601
3602       Name:            ip_frag (aka nw_frag)
3603       Width:           8 bits (only the least-significant 2 bits may be nonzero)
3604       Format:          frag
3605       Masking:         arbitrary bitwise masks
3606       Prerequisites:   IPv4/IPv6
3607       Access:          read-only
3608
3609       OpenFlow 1.0:    not supported
3610       OpenFlow 1.1:    not supported
3611       OXM:             none
3612       NXM:             NXM_NX_IP_FRAG (26) since Open vSwitch 1.3
3613
3614       Specifies what kinds of IP fragments or  non-fragments  to  match.  The
3615       value  for this field is most conveniently specified as one of the fol‐
3616       lowing:
3617
3618              no     Match only non-fragmented packets.
3619
3620              yes    Matches all fragments.
3621
3622              first  Matches only fragments with offset 0.
3623
3624              later  Matches only fragments with nonzero offset.
3625
3626              not_later
3627                     Matches non-fragmented packets and  fragments  with  zero
3628                     offset.
3629
3630       The field is internally formatted as 2 bits: bit 0 is 1 for an IP frag‐
3631       ment with any offset (and otherwise 0), and bit 1 is 1 for an IP  frag‐
3632       ment with nonzero offset (and otherwise 0), like so:
3633
3634        NXM_NX_IP_FRAG
3635        <------------>
3636         6     1    1
3637       +----+-----+---+
3638       |zero|later|any|
3639       +----+-----+---+
3640         0
3641
3642
3643       Even  though  2  bits have 4 possible values, this field only uses 3 of
3644       them:
3645
3646              ·      A packet that is not an IP fragment has value 0.
3647
3648              ·      A packet that is an IP fragment with offset 0 (the  first
3649                     fragment) has bit 0 set and thus value 1.
3650
3651              ·      A  packet  that is an IP fragment with nonzero offset has
3652                     bits 0 and 1 set and thus value 3.
3653
3654       The switch may reject matches against values that can never appear.
3655
3656       It is important to understand how this field interacts with  the  Open‐
3657       Flow fragment handling mode:
3658
3659              ·      In  OFPC_FRAG_DROP mode, the OpenFlow switch drops all IP
3660                     fragments before they reach  the  flow  table,  so  every
3661                     packet  that  is available for matching will have value 0
3662                     in this field.
3663
3664              ·      Open vSwitch does not implement OFPC_FRAG_REASM mode, but
3665                     if  it  did then IP fragments would be reassembled before
3666                     they reached the flow table and again every packet avail‐
3667                     able for matching would always have value 0.
3668
3669              ·      In  OFPC_FRAG_NORMAL mode, all three values are possible,
3670                     but OpenFlow 1.0 says that fragments’ transport ports are
3671                     always  0,  even for the first fragment, so this does not
3672                     provide much extra information.
3673
3674              ·      In OFPC_FRAG_NX_MATCH mode, all three values  are  possi‐
3675                     ble.  For  fragments with offset 0, Open vSwitch makes L4
3676                     header information available.
3677
3678       Thus, this field is likely to be most useful for an Open vSwitch switch
3679       configured  in  OFPC_FRAG_NX_MATCH  mode.  See  the  description of the
3680       set-frags command in ovs-ofctl(8), for more details.
3681
3682     IPv4/IPv6 TOS Fields
3683
3684       IPv4 and IPv6 contain a one-byte ``type of service’’ or TOS field  that
3685       has the following format:
3686
3687        type of service
3688        <------------->
3689           6       2
3690       +--------+------+
3691       |  DSCP  | ECN  |
3692       +--------+------+
3693
3694
3695       IPv4/v6 DSCP (Bits 2-7) Field
3696
3697       Name:            nw_tos
3698       Width:           8 bits
3699       Format:          decimal
3700       Masking:         not maskable
3701       Prerequisites:   IPv4/IPv6
3702       Access:          read/write
3703       OpenFlow 1.0:    yes (exact match only)
3704       OpenFlow 1.1:    yes (exact match only)
3705
3706       OXM:             none
3707       NXM:             NXM_OF_IP_TOS (5) since Open vSwitch 1.1
3708
3709       This field is the TOS byte with the two ECN bits cleared to 0:
3710
3711        NXM_OF_IP_TOS
3712        <----------->
3713          6      2
3714       +------+------+
3715       | DSCP | zero |
3716       +------+------+
3717                 0
3718
3719
3720       IPv4/v6 DSCP (Bits 0-5) Field
3721
3722       Name:            ip_dscp
3723       Width:           8 bits (only the least-significant 6 bits may be nonzero)
3724       Format:          decimal
3725       Masking:         not maskable
3726       Prerequisites:   IPv4/IPv6
3727
3728       Access:          read/write
3729       OpenFlow 1.0:    yes (exact match only)
3730       OpenFlow 1.1:    yes (exact match only)
3731       OXM:             OXM_OF_IP_DSCP  (8)  since  OpenFlow 1.2 and Open vSwitch
3732                        1.7
3733       NXM:             none
3734
3735       This field is the TOS byte shifted right to put the DSCP bits in the  6
3736       least-significant bits:
3737
3738        OXM_OF_IP_DSCP
3739        <------------>
3740           2      6
3741       +-------+------+
3742       | zero  | DSCP |
3743       +-------+------+
3744           0
3745
3746
3747       IPv4/v6 ECN Field
3748
3749
3750       Name:            nw_ecn (aka ip_ecn)
3751       Width:           8 bits (only the least-significant 2 bits may be nonzero)
3752       Format:          decimal
3753       Masking:         not maskable
3754       Prerequisites:   IPv4/IPv6
3755       Access:          read/write
3756       OpenFlow 1.0:    not supported
3757       OpenFlow 1.1:    yes (exact match only)
3758       OXM:             OXM_OF_IP_ECN (9) since OpenFlow 1.2 and Open vSwitch 1.7
3759       NXM:             NXM_NX_IP_ECN (28) since Open vSwitch 1.4
3760
3761       This field is the TOS byte with the DSCP bits cleared to 0:
3762
3763        OXM_OF_IP_ECN
3764        <----------->
3765           6      2
3766       +-------+-----+
3767       | zero  | ECN |
3768       +-------+-----+
3769           0
3770
3771

LAYER 3: ARP FIELDS

3773   Summary:
3774       Name      Bytes   Mask   RW?   Prereqs   NXM/OXM Support
3775       ────────  ──────  ─────  ────  ────────  ─────────────────────
3776       arp_op    2       no     yes   ARP       OF 1.2+ and OVS 1.1+
3777       arp_spa   4       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3778       arp_tpa   4       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3779       arp_sha   6       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3780
3781       arp_tha   6       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3782
3783       In  theory,  Address Resolution Protocol, or ARP, is a generic protocol
3784       generic protocol that can be used to obtain the hardware  address  that
3785       corresponds  to  any  higher-level  protocol  address.  In contemporary
3786       usage, ARP is used only in Ethernet networks  to  obtain  the  Ethernet
3787       address  for  a given IPv4 address. OpenFlow and Open vSwitch only sup‐
3788       port this usage of ARP. For this use case, an ARP packet has  the  fol‐
3789       lowing format, with the ARP fields exposed as Open vSwitch fields high‐
3790       lighted:
3791
3792          Ethernet                      ARP
3793        <----------->   <---------------------------------->
3794        48  48   16     16   16    8   8  16 48  16  48  16
3795       +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3796       |dst|src|type | |hrd| pro |hln|pln|op|sha|spa|tha|tpa|
3797       +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3798                0x806    1  0x800  6   4
3799
3800
3801       The ARP fields are also used for RARP, the Reverse  Address  Resolution
3802       Protocol, which shares ARP’s wire format.
3803
3804       ARP Opcode Field
3805
3806       Name:            arp_op
3807       Width:           16 bits
3808       Format:          decimal
3809       Masking:         not maskable
3810
3811       Prerequisites:   ARP
3812       Access:          read/write
3813       OpenFlow 1.0:    yes (exact match only)
3814       OpenFlow 1.1:    yes (exact match only)
3815       OXM:             OXM_OF_ARP_OP (21) since OpenFlow 1.2 and Open vSwitch
3816                        1.7
3817       NXM:             NXM_OF_ARP_OP (15) since Open vSwitch 1.1
3818
3819       Even though this is a 16-bit field, Open vSwitch does not  support  ARP
3820       opcodes greater than 255; it treats them to zero. This works adequately
3821       because in practice ARP and RARP only use opcodes 1 through 4.
3822
3823       ARP Source IPv4 Address Field
3824
3825       Name:            arp_spa
3826       Width:           32 bits
3827       Format:          IPv4
3828       Masking:         arbitrary bitwise masks
3829       Prerequisites:   ARP
3830
3831       Access:          read/write
3832       OpenFlow 1.0:    yes (CIDR match only)
3833       OpenFlow 1.1:    yes
3834       OXM:             OXM_OF_ARP_SPA  (22)  since  OpenFlow  1.2  and   Open
3835                        vSwitch 1.7
3836       NXM:             NXM_OF_ARP_SPA (16) since Open vSwitch 1.1
3837
3838       ARP Target IPv4 Address Field
3839
3840
3841       Name:            arp_tpa
3842       Width:           32 bits
3843       Format:          IPv4
3844       Masking:         arbitrary bitwise masks
3845       Prerequisites:   ARP
3846       Access:          read/write
3847       OpenFlow 1.0:    yes (CIDR match only)
3848       OpenFlow 1.1:    yes
3849
3850
3851       OXM:             OXM_OF_ARP_TPA   (23)  since  OpenFlow  1.2  and  Open
3852                        vSwitch 1.7
3853       NXM:             NXM_OF_ARP_TPA (17) since Open vSwitch 1.1
3854
3855       ARP Source Ethernet Address Field
3856
3857       Name:            arp_sha
3858       Width:           48 bits
3859       Format:          Ethernet
3860
3861       Masking:         arbitrary bitwise masks
3862       Prerequisites:   ARP
3863       Access:          read/write
3864       OpenFlow 1.0:    not supported
3865       OpenFlow 1.1:    not supported
3866       OXM:             OXM_OF_ARP_SHA  (24)  since  OpenFlow  1.2  and   Open
3867                        vSwitch 1.7
3868       NXM:             NXM_NX_ARP_SHA (17) since Open vSwitch 1.1
3869
3870       ARP Target Ethernet Address Field
3871
3872       Name:            arp_tha
3873       Width:           48 bits
3874       Format:          Ethernet
3875       Masking:         arbitrary bitwise masks
3876       Prerequisites:   ARP
3877       Access:          read/write
3878       OpenFlow 1.0:    not supported
3879       OpenFlow 1.1:    not supported
3880
3881       OXM:             OXM_OF_ARP_THA   (25)  since  OpenFlow  1.2  and  Open
3882                        vSwitch 1.7
3883       NXM:             NXM_NX_ARP_THA (18) since Open vSwitch 1.1
3884

LAYER 3: NSH FIELDS

3886   Summary:
3887       Name               Bytes             Mask   RW?   Prereqs   NXM/OXM Support
3888
3889       ─────────────────  ────────────────  ─────  ────  ────────  ────────────────
3890       nsh_flags          1                 yes    yes   NSH       OVS 2.8+
3891       nsh_ttl            1                 no     yes   NSH       OVS 2.9+
3892       nsh_mdtype         1                 no     no    NSH       OVS 2.8+
3893
3894       nsh_np             1                 no     no    NSH       OVS 2.8+
3895       nsh_spi aka nsp    4 (low 24 bits)   no     yes   NSH       OVS 2.8+
3896       nsh_si aka nsi     1                 no     yes   NSH       OVS 2.8+
3897       nsh_c1 aka nshc1   4                 yes    yes   NSH       OVS 2.8+
3898
3899       nsh_c2 aka nshc2   4                 yes    yes   NSH       OVS 2.8+
3900       nsh_c3 aka nshc3   4                 yes    yes   NSH       OVS 2.8+
3901       nsh_c4 aka nshc4   4                 yes    yes   NSH       OVS 2.8+
3902
3903       Service functions are widely deployed and essential in  many  networks.
3904       These  service  functions provide a range of features such as security,
3905       WAN acceleration, and server load balancing. Service functions  may  be
3906       instantiated  at different points in the network infrastructure such as
3907       the wide area network, data center, and so forth.
3908
3909       Prior to development of the SFC architecture [RFC 7665] and the  proto‐
3910       col  specified  in  this  document, current service function deployment
3911       models have been relatively static and bound to topology for  insertion
3912       and  policy  selection.  Furthermore, they do not adapt well to elastic
3913       service environments enabled by virtualization.
3914
3915       New data center network and cloud architectures require  more  flexible
3916       service  function  deployment  models.  Additionally, the transition to
3917       virtual platforms demands an agile service insertion  model  that  sup‐
3918       ports dynamic and elastic service delivery. Specifically, the following
3919       functions are necessary:
3920
3921              1.  The movement of service functions and application  workloads
3922                  in the network.
3923
3924              2.  The ability to easily bind service policy to granular infor‐
3925                  mation, such as per-subscriber state.
3926
3927              3.  The capability to steer traffic  to  the  requisite  service
3928                  function(s).
3929
3930       The Network Service Header (NSH) specification defines a new data plane
3931       protocol, which is an encapsulation for service  function  chains.  The
3932       NSH is designed to encapsulate an original packet or frame, and in turn
3933       be encapsulated by an outer transport encapsulation (which is  used  to
3934       deliver the NSH to NSH-aware network elements), as shown below:
3935
3936       +-----------------------+----------------------------+---------------------+
3937       |Transport Encapsulation|Network Service Header (NSH)|Original Packet/Frame|
3938       +-----------------------+----------------------------+---------------------+
3939
3940
3941       The NSH is composed of the following elements:
3942
3943              1.  Service Function Path identification.
3944
3945              2.  Indication of location within a Service Function Path.
3946
3947              3.  Optional, per packet metadata (fixed length or variable).
3948
3949       [RFC 7665] provides an overview of a service chaining architecture that
3950       clearly defines the roles of the various elements and the  scope  of  a
3951       service function chaining encapsulation. Figure 3 of [RFC 7665] depicts
3952       the SFC architectural components after classification. The NSH  is  the
3953       SFC encapsulation referenced in [RFC 7665].
3954
3955       flags field (2 bits) Field
3956
3957       Name:            nsh_flags
3958       Width:           8 bits
3959       Format:          decimal
3960       Masking:         arbitrary bitwise masks
3961       Prerequisites:   NSH
3962
3963       Access:          read/write
3964       OpenFlow 1.0:    not supported
3965       OpenFlow 1.1:    not supported
3966       OXM:             none
3967       NXM:             NXOXM_NSH_FLAGS (1) since Open vSwitch 2.8
3968
3969       TTL field (6 bits) Field
3970
3971       Name:            nsh_ttl
3972       Width:           8 bits
3973       Format:          decimal
3974
3975       Masking:         not maskable
3976       Prerequisites:   NSH
3977       Access:          read/write
3978       OpenFlow 1.0:    not supported
3979       OpenFlow 1.1:    not supported
3980
3981       OXM:             none
3982       NXM:             NXOXM_NSH_TTL (10) since Open vSwitch 2.9
3983
3984       mdtype field (8 bits) Field
3985
3986
3987       Name:            nsh_mdtype
3988       Width:           8 bits
3989       Format:          decimal
3990       Masking:         not maskable
3991       Prerequisites:   NSH
3992
3993       Access:          read-only
3994       OpenFlow 1.0:    not supported
3995       OpenFlow 1.1:    not supported
3996       OXM:             none
3997       NXM:             NXOXM_NSH_MDTYPE (2) since Open vSwitch 2.8
3998
3999       np (next protocol) field (8 bits) Field
4000
4001       Name:            nsh_np
4002       Width:           8 bits
4003       Format:          decimal
4004
4005       Masking:         not maskable
4006       Prerequisites:   NSH
4007       Access:          read-only
4008       OpenFlow 1.0:    not supported
4009       OpenFlow 1.1:    not supported
4010
4011       OXM:             none
4012       NXM:             NXOXM_NSH_NP (3) since Open vSwitch 2.8
4013
4014       spi (service path identifier) field (24 bits) Field
4015
4016
4017       Name:            nsh_spi (aka nsp)
4018       Width:           32 bits (only the least-significant 24 bits may be nonzero)
4019       Format:          hexadecimal
4020       Masking:         not maskable
4021       Prerequisites:   NSH
4022
4023       Access:          read/write
4024       OpenFlow 1.0:    not supported
4025       OpenFlow 1.1:    not supported
4026       OXM:             none
4027       NXM:             NXOXM_NSH_SPI (4) since Open vSwitch 2.8
4028
4029       si (service index) field (8 bits) Field
4030
4031       Name:            nsh_si (aka nsi)
4032       Width:           8 bits
4033       Format:          decimal
4034
4035       Masking:         not maskable
4036       Prerequisites:   NSH
4037       Access:          read/write
4038       OpenFlow 1.0:    not supported
4039       OpenFlow 1.1:    not supported
4040
4041       OXM:             none
4042       NXM:             NXOXM_NSH_SI (5) since Open vSwitch 2.8
4043
4044       c1 (Network Platform Context) field (32 bits) Field
4045
4046
4047       Name:            nsh_c1 (aka nshc1)
4048       Width:           32 bits
4049       Format:          hexadecimal
4050       Masking:         arbitrary bitwise masks
4051       Prerequisites:   NSH
4052
4053       Access:          read/write
4054       OpenFlow 1.0:    not supported
4055       OpenFlow 1.1:    not supported
4056       OXM:             none
4057       NXM:             NXOXM_NSH_C1 (6) since Open vSwitch 2.8
4058
4059       c2 (Network Shared Context) field (32 bits) Field
4060
4061       Name:            nsh_c2 (aka nshc2)
4062       Width:           32 bits
4063       Format:          hexadecimal
4064
4065       Masking:         arbitrary bitwise masks
4066       Prerequisites:   NSH
4067       Access:          read/write
4068       OpenFlow 1.0:    not supported
4069       OpenFlow 1.1:    not supported
4070
4071       OXM:             none
4072       NXM:             NXOXM_NSH_C2 (7) since Open vSwitch 2.8
4073
4074       c3 (Service Platform Context) field (32 bits) Field
4075
4076
4077       Name:            nsh_c3 (aka nshc3)
4078       Width:           32 bits
4079       Format:          hexadecimal
4080       Masking:         arbitrary bitwise masks
4081       Prerequisites:   NSH
4082
4083       Access:          read/write
4084       OpenFlow 1.0:    not supported
4085       OpenFlow 1.1:    not supported
4086       OXM:             none
4087       NXM:             NXOXM_NSH_C3 (8) since Open vSwitch 2.8
4088
4089       c4 (Service Shared Context) field (32 bits) Field
4090
4091       Name:            nsh_c4 (aka nshc4)
4092       Width:           32 bits
4093       Format:          hexadecimal
4094
4095       Masking:         arbitrary bitwise masks
4096       Prerequisites:   NSH
4097       Access:          read/write
4098       OpenFlow 1.0:    not supported
4099       OpenFlow 1.1:    not supported
4100
4101       OXM:             none
4102       NXM:             NXOXM_NSH_C4 (9) since Open vSwitch 2.8
4103

LAYER 4: TCP, UDP, AND SCTP FIELDS

4105   Summary:
4106       Name                 Bytes             Mask   RW?   Prereqs   NXM/OXM Support
4107
4108       ───────────────────  ────────────────  ─────  ────  ────────  ─────────────────────
4109       tcp_src aka tp_src   2                 yes    yes   TCP       OF 1.2+ and OVS 1.1+
4110       tcp_dst aka tp_dst   2                 yes    yes   TCP       OF 1.2+ and OVS 1.1+
4111       tcp_flags            2 (low 12 bits)   yes    no    TCP       OF 1.3+ and OVS 2.1+
4112
4113       udp_src              2                 yes    yes   UDP       OF 1.2+ and OVS 1.1+
4114       udp_dst              2                 yes    yes   UDP       OF 1.2+ and OVS 1.1+
4115       sctp_src             2                 yes    yes   SCTP      OF 1.2+ and OVS 2.0+
4116       sctp_dst             2                 yes    yes   SCTP      OF 1.2+ and OVS 2.0+
4117
4118       For  matching  purposes, no distinction is made whether these protocols
4119       are encapsulated within IPv4 or IPv6.
4120
4121   TCP
4122       The following diagram shows TCP within IPv4. Open vSwitch also supports
4123       TCP  in  IPv6.  Only  TCP fields implemented as Open vSwitch fields are
4124       shown:
4125
4126          Ethernet            IPv4                   TCP
4127        <----------->   <--------------->   <------------------->
4128        48  48   16           8   32  32    16  16       12
4129       +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4130       |dst|src|type | |...|proto|src|dst| |src|dst|...|flags|...| ...
4131       +---+---+-----+ +---+-----+---+---+ +---+---+---+-----+---+
4132                0x800         6
4133
4134
4135       TCP Source Port Field
4136
4137       Name:            tcp_src (aka tp_src)
4138       Width:           16 bits
4139       Format:          decimal
4140       Masking:         arbitrary bitwise masks
4141
4142       Prerequisites:   TCP
4143       Access:          read/write
4144       OpenFlow 1.0:    yes (exact match only)
4145       OpenFlow 1.1:    yes (exact match only)
4146
4147
4148       OXM:             OXM_OF_TCP_SRC  (13)  since  OpenFlow  1.2  and   Open
4149                        vSwitch 1.7
4150       NXM:             NXM_OF_TCP_SRC (9) since Open vSwitch 1.1
4151
4152       Open vSwitch 1.6 added support for bitwise matching.
4153
4154       TCP Destination Port Field
4155
4156       Name:            tcp_dst (aka tp_dst)
4157       Width:           16 bits
4158       Format:          decimal
4159
4160       Masking:         arbitrary bitwise masks
4161       Prerequisites:   TCP
4162       Access:          read/write
4163       OpenFlow 1.0:    yes (exact match only)
4164       OpenFlow 1.1:    yes (exact match only)
4165
4166       OXM:             OXM_OF_TCP_DST   (14)  since  OpenFlow  1.2  and  Open
4167                        vSwitch 1.7
4168       NXM:             NXM_OF_TCP_DST (10) since Open vSwitch 1.1
4169
4170       Open vSwitch 1.6 added support for bitwise matching.
4171
4172       TCP Flags Field
4173
4174       Name:            tcp_flags
4175       Width:           16 bits (only the least-significant 12 bits may be nonzero)
4176       Format:          TCP flags
4177
4178       Masking:         arbitrary bitwise masks
4179       Prerequisites:   TCP
4180       Access:          read-only
4181       OpenFlow 1.0:    not supported
4182       OpenFlow 1.1:    not supported
4183
4184       OXM:             ONFOXM_ET_TCP_FLAGS  (42)  since  OpenFlow  1.3  and   Open
4185                        vSwitch  2.4;  OXM_OF_TCP_FLAGS (42) since OpenFlow 1.5 and
4186                        Open vSwitch 2.3
4187       NXM:             NXM_NX_TCP_FLAGS (34) since Open vSwitch 2.1
4188
4189       This field holds the TCP flags. TCP currently defines 9 flag  bits.  An
4190       additional  3  bits  are reserved. For more information, see [RFC 793],
4191       [RFC 3168], and [RFC 3540].
4192
4193       Matches on this field are most conveniently written in  terms  of  sym‐
4194       bolic names (given in the diagram below), each preceded by either + for
4195       a flag that must be set, or - for a flag that must  be  unset,  without
4196       any  other  delimiters between the flags. Flags not mentioned are wild‐
4197       carded. For example, tcp,tcp_flags=+syn-ack matches TCP SYNs  that  are
4198       not  ACKs,  and  tcp,tcp_flags=+[200]  matches  TCP  packets  with  the
4199       reserved [200] flag set. Matches can also  be  written  as  flags/mask,
4200       where  flags  and  mask are 16-bit numbers in decimal or in hexadecimal
4201       prefixed by 0x.
4202
4203       The flag bits are:
4204
4205                 reserved      later RFCs         RFC 793
4206             <---------------> <--------> <--------------------->
4207         4     1     1     1   1   1   1   1   1   1   1   1   1
4208       +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4209       |zero|[800]|[400]|[200]|NS|CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|
4210       +----+-----+-----+-----+--+---+---+---+---+---+---+---+---+
4211         0
4212
4213
4214   UDP
4215       The following diagram shows UDP within IPv4. Open vSwitch also supports
4216       UDP  in  IPv6.  Only UDP fields that Open vSwitch exposes as fields are
4217       shown:
4218
4219          Ethernet            IPv4              UDP
4220        <----------->   <--------------->   <--------->
4221        48  48   16           8   32  32    16  16
4222       +---+---+-----+ +---+-----+---+---+ +---+---+---+
4223       |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4224       +---+---+-----+ +---+-----+---+---+ +---+---+---+
4225                0x800        17
4226
4227
4228       UDP Source Port Field
4229
4230       Name:            udp_src
4231
4232       Width:           16 bits
4233       Format:          decimal
4234       Masking:         arbitrary bitwise masks
4235       Prerequisites:   UDP
4236       Access:          read/write
4237
4238       OpenFlow 1.0:    yes (exact match only)
4239       OpenFlow 1.1:    yes (exact match only)
4240       OXM:             OXM_OF_UDP_SRC  (15)  since  OpenFlow  1.2  and   Open
4241                        vSwitch 1.7
4242       NXM:             NXM_OF_UDP_SRC (11) since Open vSwitch 1.1
4243
4244       UDP Destination Port Field
4245
4246       Name:            udp_dst
4247       Width:           16 bits
4248       Format:          decimal
4249
4250       Masking:         arbitrary bitwise masks
4251       Prerequisites:   UDP
4252       Access:          read/write
4253       OpenFlow 1.0:    yes (exact match only)
4254       OpenFlow 1.1:    yes (exact match only)
4255
4256       OXM:             OXM_OF_UDP_DST   (16)  since  OpenFlow  1.2  and  Open
4257                        vSwitch 1.7
4258       NXM:             NXM_OF_UDP_DST (12) since Open vSwitch 1.1
4259
4260   SCTP
4261       The following diagram shows SCTP within IPv4. Open  vSwitch  also  sup‐
4262       ports  SCTP  in  IPv6.  Only  SCTP  fields that Open vSwitch exposes as
4263       fields are shown:
4264
4265          Ethernet            IPv4             SCTP
4266        <----------->   <--------------->   <--------->
4267        48  48   16           8   32  32    16  16
4268       +---+---+-----+ +---+-----+---+---+ +---+---+---+
4269       |dst|src|type | |...|proto|src|dst| |src|dst|...| ...
4270       +---+---+-----+ +---+-----+---+---+ +---+---+---+
4271                0x800        132
4272
4273
4274       SCTP Source Port Field
4275
4276
4277       Name:            sctp_src
4278       Width:           16 bits
4279       Format:          decimal
4280       Masking:         arbitrary bitwise masks
4281       Prerequisites:   SCTP
4282       Access:          read/write
4283
4284       OpenFlow 1.0:    not supported
4285       OpenFlow 1.1:    yes (exact match only)
4286       OXM:             OXM_OF_SCTP_SRC  (17)  since  OpenFlow  1.2  and  Open
4287                        vSwitch 2.0
4288       NXM:             none
4289
4290       SCTP Destination Port Field
4291
4292       Name:            sctp_dst
4293       Width:           16 bits
4294       Format:          decimal
4295       Masking:         arbitrary bitwise masks
4296       Prerequisites:   SCTP
4297
4298       Access:          read/write
4299       OpenFlow 1.0:    not supported
4300       OpenFlow 1.1:    yes (exact match only)
4301       OXM:             OXM_OF_SCTP_DST  (18)  since  OpenFlow  1.2  and  Open
4302                        vSwitch 2.0
4303       NXM:             none
4304

LAYER 4: ICMPV4 AND ICMPV6 FIELDS

4306   Summary:
4307       Name              Bytes   Mask   RW?   Prereqs      NXM/OXM Support
4308       ────────────────  ──────  ─────  ────  ───────────  ─────────────────────
4309
4310       icmp_type         1       no     yes   ICMPv4       OF 1.2+ and OVS 1.1+
4311       icmp_code         1       no     yes   ICMPv4       OF 1.2+ and OVS 1.1+
4312       icmpv6_type       1       no     yes   ICMPv6       OF 1.2+ and OVS 1.1+
4313       icmpv6_code       1       no     yes   ICMPv6       OF 1.2+ and OVS 1.1+
4314       nd_target         16      yes    yes   ND           OF 1.2+ and OVS 1.1+
4315
4316       nd_sll            6       yes    yes   ND solicit   OF 1.2+ and OVS 1.1+
4317       nd_tll            6       yes    yes   ND advert    OF 1.2+ and OVS 1.1+
4318       nd_reserved       4       no     yes   ND           OVS 2.11+
4319       nd_options_type   1       no     yes   ND           OVS 2.11+
4320
4321   ICMPv4
4322          Ethernet            IPv4             ICMPv4
4323        <----------->   <--------------->   <----------->
4324        48  48   16           8   32  32     8    8
4325       +---+---+-----+ +---+-----+---+---+ +----+----+---+
4326       |dst|src|type | |...|proto|src|dst| |type|code|...| ...
4327       +---+---+-----+ +---+-----+---+---+ +----+----+---+
4328                0x800         1
4329
4330
4331       ICMPv4 Type Field
4332
4333       Name:            icmp_type
4334       Width:           8 bits
4335       Format:          decimal
4336       Masking:         not maskable
4337       Prerequisites:   ICMPv4
4338       Access:          read/write
4339
4340       OpenFlow 1.0:    yes (exact match only)
4341       OpenFlow 1.1:    yes (exact match only)
4342       OXM:             OXM_OF_ICMPV4_TYPE (19) since OpenFlow  1.2  and  Open
4343                        vSwitch 1.7
4344       NXM:             NXM_OF_ICMP_TYPE (13) since Open vSwitch 1.1
4345
4346       For  historical  reasons,  in  an  ICMPv4 flow, Open vSwitch interprets
4347       matches on tp_src as actually referring to the ICMP type.
4348
4349       ICMPv4 Code Field
4350
4351       Name:            icmp_code
4352       Width:           8 bits
4353       Format:          decimal
4354       Masking:         not maskable
4355
4356       Prerequisites:   ICMPv4
4357       Access:          read/write
4358       OpenFlow 1.0:    yes (exact match only)
4359       OpenFlow 1.1:    yes (exact match only)
4360       OXM:             OXM_OF_ICMPV4_CODE (20) since OpenFlow  1.2  and  Open
4361                        vSwitch 1.7
4362       NXM:             NXM_OF_ICMP_CODE (14) since Open vSwitch 1.1
4363
4364       For  historical  reasons,  in  an  ICMPv4 flow, Open vSwitch interprets
4365       matches on tp_dst as actually referring to the ICMP code.
4366
4367   ICMPv6
4368           Ethernet            IPv6            ICMPv6
4369        <------------>   <-------------->   <----------->
4370        48  48    16          8   128 128    8    8
4371       +---+---+------+ +---+----+---+---+ +----+----+---+
4372       |dst|src| type | |...|next|src|dst| |type|code|...| ...
4373       +---+---+------+ +---+----+---+---+ +----+----+---+
4374                0x86dd        58
4375
4376
4377       ICMPv6 Type Field
4378
4379
4380       Name:            icmpv6_type
4381       Width:           8 bits
4382       Format:          decimal
4383       Masking:         not maskable
4384       Prerequisites:   ICMPv6
4385       Access:          read/write
4386       OpenFlow 1.0:    not supported
4387
4388       OpenFlow 1.1:    not supported
4389       OXM:             OXM_OF_ICMPV6_TYPE (29) since OpenFlow  1.2  and  Open
4390                        vSwitch 1.7
4391       NXM:             NXM_NX_ICMPV6_TYPE (21) since Open vSwitch 1.1
4392
4393       ICMPv6 Code Field
4394
4395
4396       Name:            icmpv6_code
4397       Width:           8 bits
4398       Format:          decimal
4399       Masking:         not maskable
4400       Prerequisites:   ICMPv6
4401       Access:          read/write
4402       OpenFlow 1.0:    not supported
4403
4404       OpenFlow 1.1:    not supported
4405       OXM:             OXM_OF_ICMPV6_CODE  (30)  since  OpenFlow 1.2 and Open
4406                        vSwitch 1.7
4407       NXM:             NXM_NX_ICMPV6_CODE (22) since Open vSwitch 1.1
4408
4409   ICMPv6 Neighbor Discovery
4410           Ethernet            IPv6              ICMPv6            ICMPv6 ND
4411        <------------>   <-------------->   <-------------->   <--------------->
4412        48  48    16          8   128 128      8     8          128
4413       +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4414       |dst|src| type | |...|next|src|dst| | type  |code|...| |target|option ...|
4415       +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4416                0x86dd        58            135/136  0
4417
4418
4419       ICMPv6 Neighbor Discovery Target IPv6 Field
4420
4421       Name:            nd_target
4422       Width:           128 bits
4423       Format:          IPv6
4424       Masking:         arbitrary bitwise masks
4425       Prerequisites:   ND
4426       Access:          read/write
4427
4428       OpenFlow 1.0:    not supported
4429       OpenFlow 1.1:    not supported
4430       OXM:             OXM_OF_IPV6_ND_TARGET (31) since OpenFlow 1.2 and Open
4431                        vSwitch 1.7
4432       NXM:             NXM_NX_ND_TARGET (23) since Open vSwitch 1.1
4433
4434       ICMPv6 Neighbor Discovery Source Ethernet Address Field
4435
4436       Name:            nd_sll
4437       Width:           48 bits
4438       Format:          Ethernet
4439       Masking:         arbitrary bitwise masks
4440       Prerequisites:   ND solicit
4441       Access:          read/write
4442       OpenFlow 1.0:    not supported
4443
4444       OpenFlow 1.1:    not supported
4445       OXM:             OXM_OF_IPV6_ND_SLL  (32)  since  OpenFlow 1.2 and Open
4446                        vSwitch 1.7
4447       NXM:             NXM_NX_ND_SLL (24) since Open vSwitch 1.1
4448
4449       ICMPv6 Neighbor Discovery Target Ethernet Address Field
4450
4451
4452       Name:            nd_tll
4453       Width:           48 bits
4454       Format:          Ethernet
4455       Masking:         arbitrary bitwise masks
4456       Prerequisites:   ND advert
4457       Access:          read/write
4458       OpenFlow 1.0:    not supported
4459
4460       OpenFlow 1.1:    not supported
4461       OXM:             OXM_OF_IPV6_ND_TLL (33) since OpenFlow  1.2  and  Open
4462                        vSwitch 1.7
4463       NXM:             NXM_NX_ND_TLL (25) since Open vSwitch 1.1
4464
4465       ICMPv6 Neighbor Discovery Reserved Field Field
4466
4467
4468       Name:            nd_reserved
4469       Width:           32 bits
4470       Format:          decimal
4471       Masking:         not maskable
4472       Prerequisites:   ND
4473       Access:          read/write
4474       OpenFlow 1.0:    not supported
4475
4476       OpenFlow 1.1:    not supported
4477       OXM:             none
4478       NXM:             ERICOXM_OF_ICMPV6_ND_RESERVED  (1)  since Open vSwitch
4479                        2.11
4480
4481       This is used to set the R,S,O bits in Neighbor Advertisement Messages
4482
4483       ICMPv6 Neighbor Discovery Options Type Field Field
4484
4485       Name:            nd_options_type
4486       Width:           8 bits
4487       Format:          decimal
4488       Masking:         not maskable
4489       Prerequisites:   ND
4490       Access:          read/write
4491
4492       OpenFlow 1.0:    not supported
4493       OpenFlow 1.1:    not supported
4494       OXM:             none
4495       NXM:             ERICOXM_OF_ICMPV6_ND_OPTIONS_TYPE   (2)   since   Open
4496                        vSwitch 2.11
4497
4498       A value of 1 indicates that the option is Source Link Layer. A value of
4499       2 indicates that the options is Target Link Layer.  See  RFC  4861  for
4500       further details.
4501

REFERENCES

4503              Casado M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown,
4504                     and S. Shenker, ``Ethane: Taking Control  of  the  Enter‐
4505                     prise,’’ Computer Communications Review, October 2007.
4506
4507              ERSPAN M. Foschiano, K. Ghosh, M. Mehta, ``Cisco Systems’ Encap‐
4508                     sulated Remote Switch Port Analyzer (ERSPAN),’’ ⟨https://
4509                     tools.ietf.org/html/draft-foschiano-erspan-03⟩ .
4510
4511              EXT-56 J.  Tonsing,  ``Permit  one  of a set of prerequisites to
4512                     apply, e.g. don’t preclude non-Ethernet media,’’
4513https://rs.opennetworking.org/bugs/browse/EXT-56⟩   (ONF
4514                     members only).
4515
4516              EXT-112
4517                     J. Tourrilhes, ``Support non-Ethernet packets  throughout
4518                     the pipeline,’’ ⟨https://rs.opennetworking.org/bugs/
4519                     browse/EXT-112⟩ (ONF members only).
4520
4521              EXT-134
4522                     J. Tourrilhes, ``Match first  nibble  of  the  MPLS  pay‐
4523                     load,’’ ⟨https://rs.opennetworking.org/bugs/browse/
4524                     EXT-134⟩ (ONF members only).
4525
4526              Geneve J. Gross, I. Ganga, and T.  Sridhar,  editors,  ``Geneve:
4527                     Generic Network Virtualization Encapsulation,’’ ⟨https://
4528                     datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/⟩ .
4529
4530              IEEE OUI
4531                     IEEE Standards Association,  ``MAC  Address  Block  Large
4532                     (MA-L),’’ ⟨https://standards.ieee.org/develop/regauth/
4533                     oui/index.html⟩ .
4534
4535              NSH    P.  Quinn  and  U.  Elzur,  editors,  ``Network   Service
4536                     Header,’’ ⟨https://datatracker.ietf.org/doc/
4537                     draft-ietf-sfc-nsh/⟩ .
4538
4539              OpenFlow 1.0.1
4540                     Open Networking  Foundation,  ``OpenFlow  Switch  Errata,
4541                     Version 1.0.1,’’ June 2012.
4542
4543              OpenFlow 1.1
4544                     OpenFlow Consortium, ``OpenFlow Switch Specification Ver‐
4545                     sion 1.1.0 Implemented (Wire Protocol  0x02),’’  February
4546                     2011.
4547
4548              OpenFlow 1.5
4549                     Open  Networking Foundation, ``OpenFlow Switch Specifica‐
4550                     tion Version 1.5.0 (Protocol  version  0x06),’’  December
4551                     2014.
4552
4553              OpenFlow Extensions 1.3.x Package 2
4554                     Open  Networking  Foundation, ``OpenFlow Extensions 1.3.x
4555                     Package 2,’’ December 2013.
4556
4557              TCP Flags Match Field Extension
4558                     Open  Networking  Foundation,  ``TCP  flags  match  field
4559                     Extension,’’ December 2014. In [OpenFlow Extensions 1.3.x
4560                     Package 2].
4561
4562              Pepelnjak
4563                     I. Pepelnjak, ``OpenFlow and Fermi Estimates,’’ ⟨http://
4564                     blog.ipspace.net/2013/09/openflow-and-fermi-esti‐
4565                     mates.html⟩ .
4566
4567              RFC 793
4568                     ``Transmission Control Protocol,’’ ⟨http://www.ietf.org/
4569                     rfc/rfc793.txt⟩ .
4570
4571              RFC 3032
4572                     E.  Rosen,  D.  Tappan, G. Fedorkow, Y. Rekhter, D. Fari‐
4573                     nacci, T. Li, and A. Conta,  ``MPLS  Label  Stack  Encod‐
4574                     ing,’’ ⟨http://www.ietf.org/rfc/rfc3032.txt⟩ .
4575
4576              RFC 3168
4577                     K.  Ramakrishnan,  S. Floyd, and D. Black, ``The Addition
4578                     of Explicit Congestion Notification (ECN) to IP,’’
4579https://tools.ietf.org/html/rfc3168⟩ .
4580
4581              RFC 3540
4582                     N.  Spring,  D.  Wetherall, and D. Ely, ``Robust Explicit
4583                     Congestion Notification (ECN) Signaling with Nonces,’’
4584https://tools.ietf.org/html/rfc3540⟩ .
4585
4586              RFC 4632
4587                     V.  Fuller  and  T.  Li, ``Classless Inter-domain Routing
4588                     (CIDR): The Internet Address Assignment  and  Aggregation
4589                     Plan,’’ ⟨https://tools.ietf.org/html/rfc4632⟩ .
4590
4591              RFC 5462
4592                     L.  Andersson and R. Asati, ``Multiprotocol Label Switch‐
4593                     ing (MPLS) Label Stack Entry: ``EXP’’  Field  Renamed  to
4594                     ``Traffic Class’’ Field,’’ ⟨http://www.ietf.org/rfc/
4595                     rfc5462.txt⟩ .
4596
4597              RFC 6830
4598                     D. Farinacci, V. Fuller, D. Meyer, and  D.  Lewis,  ``The
4599                     Locator/ID Separation Protocol (LISP),’’ ⟨http://
4600                     www.ietf.org/rfc/rfc6830.txt⟩ .
4601
4602              RFC 7348
4603                     M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L.  Kreeger,
4604                     T. Sridhar, M. Bursell, and C. Wright, ``Virtual eXtensi‐
4605                     ble Local Area Network (VXLAN): A Framework for  Overlay‐
4606                     ing  Virtualized  Layer 2 Networks over Layer 3 Networks,
4607                     ’’ ⟨https://tools.ietf.org/html/rfc7348⟩ .
4608
4609              RFC 7665
4610                     J. Halpern, Ed. and C. Pignataro, Ed., ``Service Function
4611                     Chaining (SFC) Architecture,’’ ⟨https://tools.ietf.org/
4612                     html/rfc7665⟩ .
4613
4614              Srinivasan
4615                     V. Srinivasan, S. Suriy, and G. Varghese, ``Packet  Clas‐
4616                     sification using Tuple Space Search,’’ SIGCOMM 1999.
4617
4618              Pagiamtzis
4619                     K.  Pagiamtzis  and A. Sheikholeslami, ``Content-address‐
4620                     able memory (CAM) circuits and architectures: A  tutorial
4621                     and  survey,’’ IEEE Journal of Solid-State Circuits, vol.
4622                     41, no. 3, pp. 712-727, March 2006.
4623
4624              VXLAN Group Policy Option
4625                     M. Smith and L. Kreeger, `` VXLAN Group Policy  Option.’’
4626                     Internet-Draft.  ⟨https://tools.ietf.org/html/
4627                     draft-smith-vxlan-group-policy⟩ .
4628

AUTHORS

4630       Ben Pfaff, with advice from Justin Pettit and Jean Tourrilhes.
4631
4632
4633
4634Open vSwitch                        2.12.0                       ovs-fields(7)
Impressum