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                   OXM_OF           (none)       0x8000
830                   OXM_OF_PKT_REG   (none)       0x8001
831                   NXOXM_ET         0x00002320   0xffff
832                   NXOXM_NSH        0x005ad650   0xffff
833                   ONFOXM_ET        0x4f4e4600   0xffff
834
835                   For more information on OXM/NXM classes and vendors,  refer
836                   back  to  OpenFlow  1.2 under Evolution of OpenFlow Fields.
837                   The number is the field number within the class and vendor.
838                   The OpenFlow spec is the version of OpenFlow that standard‐
839                   ized the code point. It is  omitted  for  NXM  code  points
840                   because they are nonstandard. The version is the version of
841                   Open vSwitch that first supported the code point.
842

CONJUNCTIVE MATCH FIELDS

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

TUNNEL FIELDS

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

METADATA FIELDS

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

CONNECTION TRACKING FIELDS

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

REGISTER FIELDS

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

LAYER 2 (ETHERNET) FIELDS

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

VLAN FIELDS

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

LAYER 2.5: MPLS FIELDS

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

LAYER 3: IPV4 AND IPV6 FIELDS

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

LAYER 3: ARP FIELDS

3809   Summary:
3810       Name      Bytes   Mask   RW?   Prereqs   NXM/OXM Support
3811       ────────  ──────  ─────  ────  ────────  ─────────────────────
3812
3813       arp_op    2       no     yes   ARP       OF 1.2+ and OVS 1.1+
3814       arp_spa   4       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3815       arp_tpa   4       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3816       arp_sha   6       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3817       arp_tha   6       yes    yes   ARP       OF 1.2+ and OVS 1.1+
3818
3819       In  theory,  Address Resolution Protocol, or ARP, is a generic protocol
3820       generic protocol that can be used to obtain the hardware  address  that
3821       corresponds  to  any  higher-level  protocol  address.  In contemporary
3822       usage, ARP is used only in Ethernet networks  to  obtain  the  Ethernet
3823       address  for  a given IPv4 address. OpenFlow and Open vSwitch only sup‐
3824       port this usage of ARP. For this use case, an ARP packet has  the  fol‐
3825       lowing format, with the ARP fields exposed as Open vSwitch fields high‐
3826       lighted:
3827
3828          Ethernet                      ARP
3829        <----------->   <---------------------------------->
3830        48  48   16     16   16    8   8  16 48  16  48  16
3831       +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3832       |dst|src|type | |hrd| pro |hln|pln|op|sha|spa|tha|tpa|
3833       +---+---+-----+ +---+-----+---+---+--+---+---+---+---+
3834                0x806    1  0x800  6   4
3835
3836
3837       The ARP fields are also used for RARP, the Reverse  Address  Resolution
3838       Protocol, which shares ARP’s wire format.
3839
3840       ARP Opcode Field
3841
3842
3843       Name:            arp_op
3844       Width:           16 bits
3845       Format:          decimal
3846       Masking:         not maskable
3847       Prerequisites:   ARP
3848
3849       Access:          read/write
3850       OpenFlow 1.0:    yes (exact match only)
3851       OpenFlow 1.1:    yes (exact match only)
3852       OXM:             OXM_OF_ARP_OP (21) since OpenFlow 1.2 and Open vSwitch
3853                        1.7
3854
3855       NXM:             NXM_OF_ARP_OP (15) since Open vSwitch 1.1
3856
3857       Even though this is a 16-bit field, Open vSwitch does not  support  ARP
3858       opcodes greater than 255; it treats them to zero. This works adequately
3859       because in practice ARP and RARP only use opcodes 1 through 4.
3860
3861       ARP Source IPv4 Address Field
3862
3863       Name:            arp_spa
3864       Width:           32 bits
3865       Format:          IPv4
3866
3867       Masking:         arbitrary bitwise masks
3868       Prerequisites:   ARP
3869       Access:          read/write
3870       OpenFlow 1.0:    yes (CIDR match only)
3871       OpenFlow 1.1:    yes
3872
3873       OXM:             OXM_OF_ARP_SPA  (22)  since  OpenFlow  1.2  and   Open
3874                        vSwitch 1.7
3875       NXM:             NXM_OF_ARP_SPA (16) since Open vSwitch 1.1
3876
3877       ARP Target IPv4 Address Field
3878
3879       Name:            arp_tpa
3880       Width:           32 bits
3881       Format:          IPv4
3882       Masking:         arbitrary bitwise masks
3883       Prerequisites:   ARP
3884
3885       Access:          read/write
3886       OpenFlow 1.0:    yes (CIDR match only)
3887       OpenFlow 1.1:    yes
3888       OXM:             OXM_OF_ARP_TPA   (23)  since  OpenFlow  1.2  and  Open
3889                        vSwitch 1.7
3890
3891       NXM:             NXM_OF_ARP_TPA (17) since Open vSwitch 1.1
3892
3893       ARP Source Ethernet Address Field
3894
3895       Name:            arp_sha
3896
3897       Width:           48 bits
3898       Format:          Ethernet
3899       Masking:         arbitrary bitwise masks
3900       Prerequisites:   ARP
3901       Access:          read/write
3902
3903       OpenFlow 1.0:    not supported
3904       OpenFlow 1.1:    not supported
3905       OXM:             OXM_OF_ARP_SHA  (24)  since  OpenFlow  1.2  and   Open
3906                        vSwitch 1.7
3907       NXM:             NXM_NX_ARP_SHA (17) since Open vSwitch 1.1
3908
3909       ARP Target Ethernet Address Field
3910
3911       Name:            arp_tha
3912       Width:           48 bits
3913       Format:          Ethernet
3914
3915       Masking:         arbitrary bitwise masks
3916       Prerequisites:   ARP
3917       Access:          read/write
3918       OpenFlow 1.0:    not supported
3919       OpenFlow 1.1:    not supported
3920
3921       OXM:             OXM_OF_ARP_THA   (25)  since  OpenFlow  1.2  and  Open
3922                        vSwitch 1.7
3923       NXM:             NXM_NX_ARP_THA (18) since Open vSwitch 1.1
3924

LAYER 3: NSH FIELDS

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

LAYER 4: TCP, UDP, AND SCTP FIELDS

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

LAYER 4: ICMPV4 AND ICMPV6 FIELDS

4353   Summary:
4354       Name          Bytes   Mask   RW?   Prereqs      NXM/OXM Support
4355       ────────────  ──────  ─────  ────  ───────────  ─────────────────────
4356
4357       icmp_type     1       no     yes   ICMPv4       OF 1.2+ and OVS 1.1+
4358       icmp_code     1       no     yes   ICMPv4       OF 1.2+ and OVS 1.1+
4359       icmpv6_type   1       no     yes   ICMPv6       OF 1.2+ and OVS 1.1+
4360       icmpv6_code   1       no     yes   ICMPv6       OF 1.2+ and OVS 1.1+
4361       nd_target     16      yes    yes   ND           OF 1.2+ and OVS 1.1+
4362
4363       nd_sll        6       yes    yes   ND solicit   OF 1.2+ and OVS 1.1+
4364       nd_tll        6       yes    yes   ND advert    OF 1.2+ and OVS 1.1+
4365
4366   ICMPv4
4367          Ethernet            IPv4             ICMPv4
4368        <----------->   <--------------->   <----------->
4369        48  48   16           8   32  32     8    8
4370       +---+---+-----+ +---+-----+---+---+ +----+----+---+
4371       |dst|src|type | |...|proto|src|dst| |type|code|...| ...
4372       +---+---+-----+ +---+-----+---+---+ +----+----+---+
4373                0x800         1
4374
4375
4376       ICMPv4 Type Field
4377
4378       Name:            icmp_type
4379       Width:           8 bits
4380
4381       Format:          decimal
4382       Masking:         not maskable
4383       Prerequisites:   ICMPv4
4384       Access:          read/write
4385       OpenFlow 1.0:    yes (exact match only)
4386
4387       OpenFlow 1.1:    yes (exact match only)
4388       OXM:             OXM_OF_ICMPV4_TYPE (19) since OpenFlow  1.2  and  Open
4389                        vSwitch 1.7
4390       NXM:             NXM_OF_ICMP_TYPE (13) since Open vSwitch 1.1
4391
4392       For  historical  reasons,  in  an  ICMPv4 flow, Open vSwitch interprets
4393       matches on tp_src as actually referring to the ICMP type.
4394
4395       ICMPv4 Code Field
4396
4397       Name:            icmp_code
4398
4399       Width:           8 bits
4400       Format:          decimal
4401       Masking:         not maskable
4402       Prerequisites:   ICMPv4
4403       Access:          read/write
4404
4405       OpenFlow 1.0:    yes (exact match only)
4406       OpenFlow 1.1:    yes (exact match only)
4407       OXM:             OXM_OF_ICMPV4_CODE (20) since OpenFlow  1.2  and  Open
4408                        vSwitch 1.7
4409       NXM:             NXM_OF_ICMP_CODE (14) since Open vSwitch 1.1
4410
4411       For  historical  reasons,  in  an  ICMPv4 flow, Open vSwitch interprets
4412       matches on tp_dst as actually referring to the ICMP code.
4413
4414   ICMPv6
4415           Ethernet            IPv6            ICMPv6
4416        <------------>   <-------------->   <----------->
4417        48  48    16          8   128 128    8    8
4418       +---+---+------+ +---+----+---+---+ +----+----+---+
4419       |dst|src| type | |...|next|src|dst| |type|code|...| ...
4420       +---+---+------+ +---+----+---+---+ +----+----+---+
4421                0x86dd        58
4422
4423
4424       ICMPv6 Type Field
4425
4426       Name:            icmpv6_type
4427       Width:           8 bits
4428
4429       Format:          decimal
4430       Masking:         not maskable
4431       Prerequisites:   ICMPv6
4432       Access:          read/write
4433       OpenFlow 1.0:    not supported
4434
4435       OpenFlow 1.1:    not supported
4436       OXM:             OXM_OF_ICMPV6_TYPE (29) since OpenFlow  1.2  and  Open
4437                        vSwitch 1.7
4438       NXM:             NXM_NX_ICMPV6_TYPE (21) since Open vSwitch 1.1
4439
4440       ICMPv6 Code Field
4441
4442       Name:            icmpv6_code
4443       Width:           8 bits
4444       Format:          decimal
4445       Masking:         not maskable
4446
4447       Prerequisites:   ICMPv6
4448       Access:          read/write
4449       OpenFlow 1.0:    not supported
4450       OpenFlow 1.1:    not supported
4451
4452
4453       OXM:             OXM_OF_ICMPV6_CODE  (30)  since  OpenFlow 1.2 and Open
4454                        vSwitch 1.7
4455       NXM:             NXM_NX_ICMPV6_CODE (22) since Open vSwitch 1.1
4456
4457   ICMPv6 Neighbor Discovery
4458           Ethernet            IPv6              ICMPv6            ICMPv6 ND
4459        <------------>   <-------------->   <-------------->   <--------------->
4460        48  48    16          8   128 128      8     8          128
4461       +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4462       |dst|src| type | |...|next|src|dst| | type  |code|...| |target|option ...|
4463       +---+---+------+ +---+----+---+---+ +-------+----+---+ +------+----------+
4464                0x86dd        58            135/136  0
4465
4466
4467       ICMPv6 Neighbor Discovery Target IPv6 Field
4468
4469       Name:            nd_target
4470       Width:           128 bits
4471       Format:          IPv6
4472       Masking:         arbitrary bitwise masks
4473
4474       Prerequisites:   ND
4475       Access:          read/write
4476       OpenFlow 1.0:    not supported
4477       OpenFlow 1.1:    not supported
4478       OXM:             OXM_OF_IPV6_ND_TARGET (31) since OpenFlow 1.2 and Open
4479                        vSwitch 1.7
4480
4481       NXM:             NXM_NX_ND_TARGET (23) since Open vSwitch 1.1
4482
4483       ICMPv6 Neighbor Discovery Source Ethernet Address Field
4484
4485       Name:            nd_sll
4486       Width:           48 bits
4487
4488       Format:          Ethernet
4489       Masking:         arbitrary bitwise masks
4490       Prerequisites:   ND solicit
4491       Access:          read/write
4492       OpenFlow 1.0:    not supported
4493       OpenFlow 1.1:    not supported
4494
4495       OXM:             OXM_OF_IPV6_ND_SLL  (32)  since  OpenFlow 1.2 and Open
4496                        vSwitch 1.7
4497       NXM:             NXM_NX_ND_SLL (24) since Open vSwitch 1.1
4498
4499       ICMPv6 Neighbor Discovery Target Ethernet Address Field
4500
4501
4502       Name:            nd_tll
4503       Width:           48 bits
4504       Format:          Ethernet
4505       Masking:         arbitrary bitwise masks
4506       Prerequisites:   ND advert
4507       Access:          read/write
4508
4509       OpenFlow 1.0:    not supported
4510       OpenFlow 1.1:    not supported
4511       OXM:             OXM_OF_IPV6_ND_TLL (33) since OpenFlow  1.2  and  Open
4512                        vSwitch 1.7
4513       NXM:             NXM_NX_ND_TLL (25) since Open vSwitch 1.1
4514

REFERENCES

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

AUTHORS

4643       Ben Pfaff, with advice from Justin Pettit and Jean Tourrilhes.
4644
4645
4646
4647Open vSwitch                        2.10.0                       ovs-fields(7)
Impressum