diff options
| author | Ben Pfaff <blp@ovn.org> | 2018-05-25 17:11:07 -0700 |
|---|---|---|
| committer | Ben Pfaff <blp@ovn.org> | 2018-06-11 15:32:00 -0700 |
| commit | 5a0e4aec1af5cf7741c490bce704577e51e536b9 (patch) | |
| tree | 0115e5184d50e22d6f6e7c7bd87a2690bdcc6ca4 /lib | |
| parent | 7be29a47576dce715f9c8b2b4f673fa623728ed0 (diff) | |
| download | openvswitch-5a0e4aec1af5cf7741c490bce704577e51e536b9.tar.gz | |
treewide: Convert leading tabs to spaces.
It's always been OVS coding style to use spaces rather than tabs for
indentation, but some tabs have snuck in over time. This commit converts
them to spaces.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
Diffstat (limited to 'lib')
| -rw-r--r-- | lib/dpif-netdev.c | 32 | ||||
| -rw-r--r-- | lib/dpif.c | 4 | ||||
| -rw-r--r-- | lib/meta-flow.xml | 2146 | ||||
| -rw-r--r-- | lib/ofp-print.c | 8 |
4 files changed, 1095 insertions, 1095 deletions
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c index 818b184ee..9390fff68 100644 --- a/lib/dpif-netdev.c +++ b/lib/dpif-netdev.c @@ -856,15 +856,15 @@ pmd_info_show_stats(struct ds *reply, } ds_put_format(reply, - "\tpackets received: %"PRIu64"\n" - "\tpacket recirculations: %"PRIu64"\n" - "\tavg. datapath passes per packet: %.02f\n" - "\temc hits: %"PRIu64"\n" - "\tmegaflow hits: %"PRIu64"\n" - "\tavg. subtable lookups per megaflow hit: %.02f\n" - "\tmiss with success upcall: %"PRIu64"\n" - "\tmiss with failed upcall: %"PRIu64"\n" - "\tavg. packets per output batch: %.02f\n", + " packets received: %"PRIu64"\n" + " packet recirculations: %"PRIu64"\n" + " avg. datapath passes per packet: %.02f\n" + " emc hits: %"PRIu64"\n" + " megaflow hits: %"PRIu64"\n" + " avg. subtable lookups per megaflow hit: %.02f\n" + " miss with success upcall: %"PRIu64"\n" + " miss with failed upcall: %"PRIu64"\n" + " avg. packets per output batch: %.02f\n", total_packets, stats[PMD_STAT_RECIRC], passes_per_pkt, stats[PMD_STAT_EXACT_HIT], stats[PMD_STAT_MASKED_HIT], lookups_per_hit, @@ -876,8 +876,8 @@ pmd_info_show_stats(struct ds *reply, } ds_put_format(reply, - "\tidle cycles: %"PRIu64" (%.02f%%)\n" - "\tprocessing cycles: %"PRIu64" (%.02f%%)\n", + " idle cycles: %"PRIu64" (%.02f%%)\n" + " processing cycles: %"PRIu64" (%.02f%%)\n", stats[PMD_CYCLES_ITER_IDLE], stats[PMD_CYCLES_ITER_IDLE] / (double) total_cycles * 100, stats[PMD_CYCLES_ITER_BUSY], @@ -888,12 +888,12 @@ pmd_info_show_stats(struct ds *reply, } ds_put_format(reply, - "\tavg cycles per packet: %.02f (%"PRIu64"/%"PRIu64")\n", + " avg cycles per packet: %.02f (%"PRIu64"/%"PRIu64")\n", total_cycles / (double) total_packets, total_cycles, total_packets); ds_put_format(reply, - "\tavg processing cycles per packet: " + " avg processing cycles per packet: " "%.02f (%"PRIu64"/%"PRIu64")\n", stats[PMD_CYCLES_ITER_BUSY] / (double) total_packets, stats[PMD_CYCLES_ITER_BUSY], total_packets); @@ -991,7 +991,7 @@ pmd_info_show_rxq(struct ds *reply, struct dp_netdev_pmd_thread *pmd) uint64_t total_cycles = 0; ds_put_format(reply, - "pmd thread numa_id %d core_id %u:\n\tisolated : %s\n", + "pmd thread numa_id %d core_id %u:\n isolated : %s\n", pmd->numa_id, pmd->core_id, (pmd->isolated) ? "true" : "false"); @@ -1011,9 +1011,9 @@ pmd_info_show_rxq(struct ds *reply, struct dp_netdev_pmd_thread *pmd) for (int j = 0; j < PMD_RXQ_INTERVAL_MAX; j++) { proc_cycles += dp_netdev_rxq_get_intrvl_cycles(rxq, j); } - ds_put_format(reply, "\tport: %-16s\tqueue-id: %2d", name, + ds_put_format(reply, " port: %-16s queue-id: %2d", name, netdev_rxq_get_queue_id(list[i].rxq->rx)); - ds_put_format(reply, "\tpmd usage: "); + ds_put_format(reply, " pmd usage: "); if (total_cycles) { ds_put_format(reply, "%2"PRIu64"", proc_cycles * 100 / total_cycles); diff --git a/lib/dpif.c b/lib/dpif.c index 3c7d3b8a2..f6a7f6a72 100644 --- a/lib/dpif.c +++ b/lib/dpif.c @@ -369,7 +369,7 @@ do_open(const char *name, const char *type, bool create, struct dpif **dpifp) netdev_close(netdev); } else { VLOG_WARN("could not open netdev %s type %s: %s", - dpif_port.name, dpif_port.type, ovs_strerror(err)); + dpif_port.name, dpif_port.type, ovs_strerror(err)); } } } else { @@ -1176,7 +1176,7 @@ dpif_execute_helper_cb(void *aux_, struct dp_packet_batch *packets_, if (!aux->meter_action) { aux->meter_action = action; } - break; + break; case OVS_ACTION_ATTR_CT: case OVS_ACTION_ATTR_OUTPUT: diff --git a/lib/meta-flow.xml b/lib/meta-flow.xml index 9ad15b3d9..0b5c1d008 100644 --- a/lib/meta-flow.xml +++ b/lib/meta-flow.xml @@ -143,14 +143,14 @@ <dt><dfn>Exact match</dfn>, e.g. <code>nw_src=10.1.2.3</code></dt> <dd> <p> - Only a particular value of the field is matched; for example, only one - particular source IP address. Exact matches are written as - <code><var>field</var>=<var>value</var></code>. The forms accepted for - <var>value</var> depend on the field. + Only a particular value of the field is matched; for example, only one + particular source IP address. Exact matches are written as + <code><var>field</var>=<var>value</var></code>. The forms accepted for + <var>value</var> depend on the field. </p> <p> - All fields support exact matches. + All fields support exact matches. </p> </dd> @@ -159,14 +159,14 @@ </dt> <dd> <p> - Specific bits in the field must have specified values; for example, - only source IP addresses in a particular subnet. Bitwise matches are - written as - <code><var>field</var>=<var>value</var>/<var>mask</var></code>, where - <var>value</var> and <var>mask</var> take one of the forms accepted for - an exact match on <var>field</var>. Some fields accept other forms for - bitwise matches; for example, <code>nw_src=10.1.0.0/255.255.0.0</code> - may also be written <code>nw_src=10.1.0.0/16</code>. + Specific bits in the field must have specified values; for example, + only source IP addresses in a particular subnet. Bitwise matches are + written as + <code><var>field</var>=<var>value</var>/<var>mask</var></code>, where + <var>value</var> and <var>mask</var> take one of the forms accepted for + an exact match on <var>field</var>. Some fields accept other forms for + bitwise matches; for example, <code>nw_src=10.1.0.0/255.255.0.0</code> + may also be written <code>nw_src=10.1.0.0/16</code>. </p> <p> @@ -186,17 +186,17 @@ <dt><dfn>Wildcard</dfn>, e.g. ``any <code>nw_src</code>''</dt> <dd> <p> - The value of the field is not constrained. Wildcarded fields may be - written as <code><var>field</var>=*</code>, although it is unusual to - mention them at all. (When specifying a wildcard explicitly in a - command invocation, be sure to using quoting to protect against shell - expansion.) + The value of the field is not constrained. Wildcarded fields may be + written as <code><var>field</var>=*</code>, although it is unusual to + mention them at all. (When specifying a wildcard explicitly in a + command invocation, be sure to using quoting to protect against shell + expansion.) </p> <p> - There is a tiny difference between wildcarding a field and not - specifying any match on a field: wildcarding a field requires - satisfying the field's prerequisites. + There is a tiny difference between wildcarding a field and not + specifying any match on a field: wildcarding a field requires + satisfying the field's prerequisites. </p> </dd> </dl> @@ -211,13 +211,13 @@ 8080}''</dt> <dd> <p> - The value of a field is one of a specified set of values; for - example, the TCP destination port is 80, 443, or 8080. + The value of a field is one of a specified set of values; for + example, the TCP destination port is 80, 443, or 8080. </p> <p> - For matches used in flows (see <cite>Flows</cite>, below), multiple - flows can simulate set matches. + For matches used in flows (see <cite>Flows</cite>, below), multiple + flows can simulate set matches. </p> </dd> @@ -225,14 +225,14 @@ 1999''</dt> <dd> <p> - The value of the field must lie within a numerical range, for - example, TCP destination ports between 1000 and 1999. + The value of the field must lie within a numerical range, for + example, TCP destination ports between 1000 and 1999. </p> <p> - Range matches can be expressed as a collection of bitwise matches. For - example, suppose that the goal is to match TCP source ports 1000 to - 1999, inclusive. The binary representations of 1000 and 1999 are: + Range matches can be expressed as a collection of bitwise matches. For + example, suppose that the goal is to match TCP source ports 1000 to + 1999, inclusive. The binary representations of 1000 and 1999 are: </p> <pre fixed="yes"> @@ -241,8 +241,8 @@ </pre> <p> - The following series of bitwise matches will match 1000 and - 1999 and all the values in between: + The following series of bitwise matches will match 1000 and + 1999 and all the values in between: </p> <pre fixed="yes"> @@ -256,7 +256,7 @@ </pre> <p> - which can be written as the following matches: + which can be written as the following matches: </p> <pre> @@ -273,8 +273,8 @@ tcp,tp_src=0x07c0/0xfff0 <dt><dfn>Inequality match</dfn>, e.g. ``<code>tcp_dst</code> ≠ 80''</dt> <dd> <p> - The value of the field differs from a specified value, for - example, all TCP destination ports except 80. + The value of the field differs from a specified value, for + example, all TCP destination ports except 80. </p> <p> @@ -1328,28 +1328,28 @@ tcp,tp_src=0x07c0/0xfff0 <dl> <dt>``Port-based'' tunnels</dt> <dd> - <p> - In this model, an OpenFlow port represents one tunnel: it matches a - particular type of tunnel traffic between two IP endpoints, with a - particular tunnel key (if keys are in use). In this situation, <ref - field="in_port"/> suffices to distinguish one tunnel from another, so - the tunnel header fields have little importance for OpenFlow - processing. (They are still populated and may be used if it is - convenient.) The tunnel header fields play no role in sending - packets out such an OpenFlow port, either, because the OpenFlow port - itself fully specifies the tunnel headers. - </p> - - <p> - The following Open vSwitch commands create a bridge - <code>br-int</code>, add port <code>tap0</code> to the bridge as - OpenFlow port 1, establish a port-based GRE tunnel between the local - host and remote IP 192.168.1.1 using GRE key 5001 as OpenFlow port 2, - and arranges to forward all traffic from <code>tap0</code> to the - tunnel and vice versa: - </p> - - <pre> + <p> + In this model, an OpenFlow port represents one tunnel: it matches a + particular type of tunnel traffic between two IP endpoints, with a + particular tunnel key (if keys are in use). In this situation, <ref + field="in_port"/> suffices to distinguish one tunnel from another, so + the tunnel header fields have little importance for OpenFlow + processing. (They are still populated and may be used if it is + convenient.) The tunnel header fields play no role in sending + packets out such an OpenFlow port, either, because the OpenFlow port + itself fully specifies the tunnel headers. + </p> + + <p> + The following Open vSwitch commands create a bridge + <code>br-int</code>, add port <code>tap0</code> to the bridge as + OpenFlow port 1, establish a port-based GRE tunnel between the local + host and remote IP 192.168.1.1 using GRE key 5001 as OpenFlow port 2, + and arranges to forward all traffic from <code>tap0</code> to the + tunnel and vice versa: + </p> + + <pre> ovs-vsctl add-br br-int ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1 ovs-vsctl add-port br-int gre0 -- @@ -1357,32 +1357,32 @@ ovs-vsctl add-port br-int gre0 -- options:remote_ip=192.168.1.1 options:key=5001 ovs-ofctl add-flow br-int in_port=1,actions=2 ovs-ofctl add-flow br-int in_port=2,actions=1 - </pre> + </pre> </dd> <dt>``Flow-based'' tunnels</dt> <dd> - <p> - In this model, one OpenFlow port represents all possible tunnels of a - given type with an endpoint on the current host, for example, all GRE - tunnels. In this situation, <ref field="in_port"/> only indicates - that traffic was received on the particular kind of tunnel. This is - where the tunnel header fields are most important: they allow the - OpenFlow tables to discriminate among tunnels based on their IP - endpoints or keys. Tunnel header fields also determine the IP - endpoints and keys of packets sent out such a tunnel port. - </p> - - <p> - The following Open vSwitch commands create a bridge - <code>br-int</code>, add port <code>tap0</code> to the - bridge as OpenFlow port 1, establish a flow-based GRE tunnel - port 3, and arranges to forward all traffic from - <code>tap0</code> to remote IP 192.168.1.1 over a GRE tunnel - with key 5001 and vice versa: - </p> - - <pre> + <p> + In this model, one OpenFlow port represents all possible tunnels of a + given type with an endpoint on the current host, for example, all GRE + tunnels. In this situation, <ref field="in_port"/> only indicates + that traffic was received on the particular kind of tunnel. This is + where the tunnel header fields are most important: they allow the + OpenFlow tables to discriminate among tunnels based on their IP + endpoints or keys. Tunnel header fields also determine the IP + endpoints and keys of packets sent out such a tunnel port. + </p> + + <p> + The following Open vSwitch commands create a bridge + <code>br-int</code>, add port <code>tap0</code> to the + bridge as OpenFlow port 1, establish a flow-based GRE tunnel + port 3, and arranges to forward all traffic from + <code>tap0</code> to remote IP 192.168.1.1 over a GRE tunnel + with key 5001 and vice versa: + </p> + + <pre> ovs-vsctl add-br br-int ovs-vsctl add-port br-int tap0 -- set interface tap0 ofport_request=1 ovs-vsctl add-port br-int allgre -- @@ -1391,42 +1391,42 @@ ovs-vsctl add-port br-int allgre -- ovs-ofctl add-flow br-int \ 'in_port=1 actions=set_tunnel:5001,set_field:192.168.1.1->tun_dst,3' ovs-ofctl add-flow br-int 'in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1' - </pre> + </pre> </dd> <dt>Mixed models.</dt> <dd> - <p> - One may define both flow-based and port-based tunnels at the - same time. For example, it is valid and possibly useful to - create and configure both <code>gre0</code> and - <code>allgre</code> tunnel ports described above. - </p> - - <p> - Traffic is attributed on ingress to the most specific - matching tunnel. For example, <code>gre0</code> is more - specific than <code>allgre</code>. Therefore, if both - exist, then <code>gre0</code> will be the ingress port for any - GRE traffic received from 192.168.1.1 with key 5001. - </p> - - <p> - On egress, traffic may be directed to any appropriate tunnel - port. If both <code>gre0</code> and <code>allgre</code> are - configured as already described, then the actions - <code>2</code> and - <code>set_tunnel:5001,set_field:192.168.1.1->tun_dst,3</code> - send the same tunnel traffic. - </p> + <p> + One may define both flow-based and port-based tunnels at the + same time. For example, it is valid and possibly useful to + create and configure both <code>gre0</code> and + <code>allgre</code> tunnel ports described above. + </p> + + <p> + Traffic is attributed on ingress to the most specific + matching tunnel. For example, <code>gre0</code> is more + specific than <code>allgre</code>. Therefore, if both + exist, then <code>gre0</code> will be the ingress port for any + GRE traffic received from 192.168.1.1 with key 5001. + </p> + + <p> + On egress, traffic may be directed to any appropriate tunnel + port. If both <code>gre0</code> and <code>allgre</code> are + configured as already described, then the actions + <code>2</code> and + <code>set_tunnel:5001,set_field:192.168.1.1->tun_dst,3</code> + send the same tunnel traffic. + </p> </dd> <dt>Intermediate models.</dt> <dd> - Ports may be configured as partially flow-based. For example, - one may define an OpenFlow port that represents tunnels - between a pair of endpoints but leaves the flow table to - discriminate on the flow key. + Ports may be configured as partially flow-based. For example, + one may define an OpenFlow port that represents tunnels + between a pair of endpoints but leaves the flow table to + discriminate on the flow key. </dd> </dl> @@ -1446,155 +1446,155 @@ ovs-ofctl add-flow br-int 'in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1' <field id="MFF_TUN_ID" title="Tunnel ID"> <p> - Many kinds of tunnels support a tunnel ID: + Many kinds of tunnels support a tunnel ID: </p> <ul> - <li> + <li> VXLAN and Geneve have a 24-bit virtual network identifier (VNI). </li> - <li>LISP has a 24-bit instance ID.</li> - <li>GRE has an optional 32-bit key.</li> - <li>STT has a 64-bit key.</li> + <li>LISP has a 24-bit instance ID.</li> + <li>GRE has an optional 32-bit key.</li> + <li>STT has a 64-bit key.</li> <li>ERSPAN has a 10-bit key (Session ID).</li> </ul> <p> - When a packet is received from a tunnel, this field holds the - tunnel ID in its least significant bits, zero-extended to fit. - This field is zero if the tunnel does not support an ID, or if - no ID is in use for a tunnel type that has an optional ID, or - if an ID of zero received, or if the packet was not received - over a tunnel. + When a packet is received from a tunnel, this field holds the + tunnel ID in its least significant bits, zero-extended to fit. + This field is zero if the tunnel does not support an ID, or if + no ID is in use for a tunnel type that has an optional ID, or + if an ID of zero received, or if the packet was not received + over a tunnel. </p> <p> - When a packet is output to a tunnel port, the tunnel - configuration determines whether the tunnel ID is taken from - this field or bound to a fixed value. See the earlier - description of ``port-based'' and ``flow-based'' tunnels for - more information. + When a packet is output to a tunnel port, the tunnel + configuration determines whether the tunnel ID is taken from + this field or bound to a fixed value. See the earlier + description of ``port-based'' and ``flow-based'' tunnels for + more information. </p> <p> - The following diagram shows the origin of this field in a - typical keyed GRE tunnel: + The following diagram shows the origin of this field in a + typical keyed GRE tunnel: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> - </header> - <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" below="47" width="0.4"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4"/> - </header> - <header name="GRE"> - <bits name="..." above="16" width="0.4"/> - <bits name="type" above="16" below="0x6558" width="0.4"/> - <bits name="key" above="32" width=".4" fill="yes"/> - </header> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" width="0.4"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> + </header> + <header name="IPv4"> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" below="47" width="0.4"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4"/> + </header> + <header name="GRE"> + <bits name="..." above="16" width="0.4"/> + <bits name="type" above="16" below="0x6558" width="0.4"/> + <bits name="key" above="32" width=".4" fill="yes"/> + </header> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" width="0.4"/> + </header> + <dots/> </diagram> </field> <field id="MFF_TUN_SRC" title="Tunnel IPv4 Source"> <p> - When a packet is received from a tunnel, this field is the - source address in the outer IP header of the tunneled packet. - This field is zero if the packet was not received over a - tunnel. + When a packet is received from a tunnel, this field is the + source address in the outer IP header of the tunneled packet. + This field is zero if the packet was not received over a + tunnel. </p> <p> - When a packet is output to a flow-based tunnel port, this - field influences the IPv4 source address used to send the - packet. If it is zero, then the kernel chooses an appropriate - IP address based using the routing table. + When a packet is output to a flow-based tunnel port, this + field influences the IPv4 source address used to send the + packet. If it is zero, then the kernel chooses an appropriate + IP address based using the routing table. </p> <p> - The following diagram shows the origin of this field in a - typical keyed GRE tunnel: + The following diagram shows the origin of this field in a + typical keyed GRE tunnel: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> - </header> - <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" below="47" width="0.4"/> - <bits name="src" above="32" width="0.4" fill="yes"/> - <bits name="dst" above="32" width="0.4"/> - </header> - <header name="GRE"> - <bits name="..." above="16" width="0.4"/> - <bits name="type" above="16" below="0x6558" width="0.4"/> - <bits name="key" above="32" width=".4"/> - </header> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" width="0.4"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> + </header> + <header name="IPv4"> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" below="47" width="0.4"/> + <bits name="src" above="32" width="0.4" fill="yes"/> + <bits name="dst" above="32" width="0.4"/> + </header> + <header name="GRE"> + <bits name="..." above="16" width="0.4"/> + <bits name="type" above="16" below="0x6558" width="0.4"/> + <bits name="key" above="32" width=".4"/> + </header> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" width="0.4"/> + </header> + <dots/> </diagram> </field> <field id="MFF_TUN_DST" title="Tunnel IPv4 Destination"> <p> - When a packet is received from a tunnel, this field is the - destination address in the outer IP header of the tunneled - packet. This field is zero if the packet was not received - over a tunnel. + When a packet is received from a tunnel, this field is the + destination address in the outer IP header of the tunneled + packet. This field is zero if the packet was not received + over a tunnel. </p> <p> - When a packet is output to a flow-based tunnel port, this - field specifies the destination to which the tunnel packet is - sent. + When a packet is output to a flow-based tunnel port, this + field specifies the destination to which the tunnel packet is + sent. </p> <p> - The following diagram shows the origin of this field in a - typical keyed GRE tunnel: + The following diagram shows the origin of this field in a + typical keyed GRE tunnel: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> - </header> - <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" below="47" width="0.4"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4" fill="yes"/> - </header> - <header name="GRE"> - <bits name="..." above="16" width="0.4"/> - <bits name="type" above="16" below="0x6558" width="0.4"/> - <bits name="key" above="32" width=".4"/> - </header> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" width="0.4"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> + </header> + <header name="IPv4"> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" below="47" width="0.4"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4" fill="yes"/> + </header> + <header name="GRE"> + <bits name="..." above="16" width="0.4"/> + <bits name="type" above="16" below="0x6558" width="0.4"/> + <bits name="key" above="32" width=".4"/> + </header> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" width="0.4"/> + </header> + <dots/> </diagram> </field> @@ -1822,16 +1822,16 @@ ovs-ofctl add-flow br-int 'in_port=3,tun_src=192.168.1.1,tun_id=5001 actions=1' </p> <diagram> - <header name="header"> - <bits name="class" above="16" width="0.6"/> - <bits name="type" above="8" width="0.5"/> - <bits name="res" above="3" below="0" width="0.25"/> - <bits name="length" above="5" width="0.4"/> - </header> + <header name="header"> + <bits name="class" above="16" width="0.6"/> + <bits name="type" above="8" width="0.5"/> + <bits name="res" above="3" below="0" width="0.25"/> + <bits name="length" above="5" width="0.4"/> + </header> <nospace/> - <header name="body"> - <bits name="value" above="4×(length - 1) bytes" width="1.7"/> - </header> + <header name="body"> + <bits name="value" above="4×(length - 1) bytes" width="1.7"/> + </header> </diagram> <p> @@ -1996,167 +1996,167 @@ ovs-ofctl add-flow br0 tun_metadata0=1234,actions=controller <field id="MFF_IN_PORT" title="Ingress Port"> <p> - The OpenFlow port on which the packet being processed arrived. - This is a 16-bit field that holds an OpenFlow 1.0 port number. - For receiving a packet, the only values that appear in this - field are: + The OpenFlow port on which the packet being processed arrived. + This is a 16-bit field that holds an OpenFlow 1.0 port number. + For receiving a packet, the only values that appear in this + field are: </p> <dl> - <dt>1 through <code>0xfeff</code> (65,279), inclusive.</dt> - <dd> - Conventional OpenFlow port numbers. - </dd> - - <dt><code>OFPP_LOCAL</code> (<code>0xfffe</code> or 65,534).</dt> - <dd> - <p> - The ``local'' port, which in Open vSwitch is always named - the same as the bridge itself. This represents a - connection between the switch and the local TCP/IP stack. - This port is where an IP address is most commonly - configured on an Open vSwitch switch. - </p> - - <p> - OpenFlow does not require a switch to have a local port, - but all existing versions of Open vSwitch have always - included a local port. <b>Future Directions:</b> Future - versions of Open vSwitch might be able to optionally omit - the local port, if someone submits code to implement such - a feature. - </p> - </dd> - - <dt><code>OFPP_NONE</code> (OpenFlow 1.0) or <code>OFPP_ANY</code> (OpenFlow 1.1+) (<code>0xffff</code> or 65,535).</dt> - <dt><code>OFPP_CONTROLLER</code> (<code>0xfffd</code> or 65,533).</dt> - <dd> - <p> - When a controller injects a packet into an OpenFlow switch - with a ``packet-out'' request, it can specify one of these - ingress ports to indicate that the packet was generated - internally rather than having been received on some port. - </p> - - <p> - OpenFlow 1.0 specified <code>OFPP_NONE</code> for this - purpose. Despite that, some controllers used - <code>OFPP_CONTROLLER</code>, and some switches only - accepted <code>OFPP_CONTROLLER</code>, so OpenFlow 1.0.2 - required support for both ports. OpenFlow 1.1 and later - were more clearly drafted to allow only - <code>OFPP_CONTROLLER</code>. For maximum compatibility, - Open vSwitch allows both ports with all OpenFlow versions. - </p> - </dd> + <dt>1 through <code>0xfeff</code> (65,279), inclusive.</dt> + <dd> + Conventional OpenFlow port numbers. + </dd> + + <dt><code>OFPP_LOCAL</code> (<code>0xfffe</code> or 65,534).</dt> + <dd> + <p> + The ``local'' port, which in Open vSwitch is always named + the same as the bridge itself. This represents a + connection between the switch and the local TCP/IP stack. + This port is where an IP address is most commonly + configured on an Open vSwitch switch. + </p> + + <p> + OpenFlow does not require a switch to have a local port, + but all existing versions of Open vSwitch have always + included a local port. <b>Future Directions:</b> Future + versions of Open vSwitch might be able to optionally omit + the local port, if someone submits code to implement such + a feature. + </p> + </dd> + + <dt><code>OFPP_NONE</code> (OpenFlow 1.0) or <code>OFPP_ANY</code> (OpenFlow 1.1+) (<code>0xffff</code> or 65,535).</dt> + <dt><code>OFPP_CONTROLLER</code> (<code>0xfffd</code> or 65,533).</dt> + <dd> + <p> + When a controller injects a packet into an OpenFlow switch + with a ``packet-out'' request, it can specify one of these + ingress ports to indicate that the packet was generated + internally rather than having been received on some port. + </p> + + <p> + OpenFlow 1.0 specified <code>OFPP_NONE</code> for this + purpose. Despite that, some controllers used + <code>OFPP_CONTROLLER</code>, and some switches only + accepted <code>OFPP_CONTROLLER</code>, so OpenFlow 1.0.2 + required support for both ports. OpenFlow 1.1 and later + were more clearly drafted to allow only + <code>OFPP_CONTROLLER</code>. For maximum compatibility, + Open vSwitch allows both ports with all OpenFlow versions. + </p> + </dd> </dl> <p> - Values not mentioned above will never appear when receiving a - packet, including the following notable values: + Values not mentioned above will never appear when receiving a + packet, including the following notable values: </p> <dl> - <dt>0</dt> - <dd> - Zero is not a valid OpenFlow port number. - </dd> - - <dt><code>OFPP_MAX</code> (<code>0xff00</code> or 65,280).</dt> - <dd> - This value has only been clearly specified as a valid port - number as of OpenFlow 1.3.3. Before that, its status was - unclear, and so Open vSwitch has never allowed - <code>OFPP_MAX</code> to be used as a port number, so - packets will never be received on this port. (Other - OpenFlow switches, of course, might use it.) - </dd> + <dt>0</dt> + <dd> + Zero is not a valid OpenFlow port number. + </dd> + + <dt><code>OFPP_MAX</code> (<code>0xff00</code> or 65,280).</dt> + <dd> + This value has only been clearly specified as a valid port + number as of OpenFlow 1.3.3. Before that, its status was + unclear, and so Open vSwitch has never allowed + <code>OFPP_MAX</code> to be used as a port number, so + packets will never be received on this port. (Other + OpenFlow switches, of course, might use it.) + </dd> <dt><code>OFPP_UNSET</code> (<code>0xfff7</code> or 65,527)</dt> - <dt><code>OFPP_IN_PORT</code> (<code>0xfff8</code> or 65,528)</dt> - <dt><code>OFPP_TABLE</code> (<code>0xfff9</code> or 65,529)</dt> - <dt><code>OFPP_NORMAL</code> (<code>0xfffa</code> or 65,530)</dt> - <dt><code>OFPP_FLOOD</code> (<code>0xfffb</code> or 65,531)</dt> - <dt><code>OFPP_ALL</code> (<code>0xfffc</code> or 65,532)</dt> - <dd> + <dt><code>OFPP_IN_PORT</code> (<code>0xfff8</code> or 65,528)</dt> + <dt><code>OFPP_TABLE</code> (<code>0xfff9</code> or 65,529)</dt> + <dt><code>OFPP_NORMAL</code> (<code>0xfffa</code> or 65,530)</dt> + <dt><code>OFPP_FLOOD</code> (<code>0xfffb</code> or 65,531)</dt> + <dt><code>OFPP_ALL</code> (<code>0xfffc</code> or 65,532)</dt> + <dd> <p> - These port numbers are used only in output actions and never - appear as ingress ports. + These port numbers are used only in output actions and never + appear as ingress ports. </p> <p> Most of these port numbers were defined in OpenFlow 1.0, but <code>OFPP_UNSET</code> was only introduced in OpenFlow 1.5. </p> - </dd> + </dd> </dl> <p> - Values that will never appear when receiving a packet may - still be matched against in the flow table. There are still - circumstances in which those flows can be matched: + Values that will never appear when receiving a packet may + still be matched against in the flow table. There are still + circumstances in which those flows can be matched: </p> <ul> - <li> - The <code>resubmit</code> Open vSwitch extension action allows a - flow table lookup with an arbitrary ingress port. - </li> - - <li> - An action that modifies the ingress port field (see below), - such as e.g. <code>load</code> or <code>set_field</code>, - followed by an action or instruction that performs another - flow table lookup, such as <code>resubmit</code> or - <code>goto_table</code>. - </li> + <li> + The <code>resubmit</code> Open vSwitch extension action allows a + flow table lookup with an arbitrary ingress port. + </li> + + <li> + An action that modifies the ingress port field (see below), + such as e.g. <code>load</code> or <code>set_field</code>, + followed by an action or instruction that performs another + flow table lookup, such as <code>resubmit</code> or + <code>goto_table</code>. + </li> </ul> <p> - This field is heavily used for matching in OpenFlow tables, - but for packet egress, it has only very limited roles: + This field is heavily used for matching in OpenFlow tables, + but for packet egress, it has only very limited roles: </p> <ul> - <li> - <p> - OpenFlow requires suppressing output actions to <ref - field="in_port"/>. That is, the following two flows both drop all - packets that arrive on port 1: - </p> - - <pre> + <li> + <p> + OpenFlow requires suppressing output actions to <ref + field="in_port"/>. That is, the following two flows both drop all + packets that arrive on port 1: + </p> + + <pre> in_port=1,actions=1 in_port=1,actions=drop - </pre> - - <p> - (This behavior is occasionally useful for flooding to a - subset of ports. Specifying <code>actions=1,2,3,4</code>, - for example, outputs to ports 1, 2, 3, and 4, omitting the - ingress port.) - </p> - </li> - - <li> - OpenFlow has a special port <code>OFPP_IN_PORT</code> (with - value 0xfff8) that outputs to the ingress port. For example, - in a switch that has four ports numbered 1 through 4, - <code>actions=1,2,3,4,in_port</code> outputs to ports 1, 2, - 3, and 4, including the ingress port. - </li> + </pre> + + <p> + (This behavior is occasionally useful for flooding to a + subset of ports. Specifying <code>actions=1,2,3,4</code>, + for example, outputs to ports 1, 2, 3, and 4, omitting the + ingress port.) + </p> + </li> + + <li> + OpenFlow has a special port <code>OFPP_IN_PORT</code> (with + value 0xfff8) that outputs to the ingress port. For example, + in a switch that has four ports numbered 1 through 4, + <code>actions=1,2,3,4,in_port</code> outputs to ports 1, 2, + 3, and 4, including the ingress port. + </li> </ul> <p> - Because the ingress port field has so little influence on packet - processing, it does not ordinarily make sense to modify the - ingress port field. The field is writable only to support the - occasional use case where the ingress port's roles in packet - egress, described above, become troublesome. For example, - <code>actions=load:0->NXM_OF_IN_PORT[],output:123</code> - will output to port 123 regardless of whether it is in the - ingress port. If the ingress port is important, then one may save - and restore it on the stack: + Because the ingress port field has so little influence on packet + processing, it does not ordinarily make sense to modify the + ingress port field. The field is writable only to support the + occasional use case where the ingress port's roles in packet + egress, described above, become troublesome. For example, + <code>actions=load:0->NXM_OF_IN_PORT[],output:123</code> + will output to port 123 regardless of whether it is in the + ingress port. If the ingress port is important, then one may save + and restore it on the stack: </p> <pre> @@ -2173,154 +2173,154 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </pre> <p> - The ability to modify the ingress port is an Open vSwitch - extension to OpenFlow. + The ability to modify the ingress port is an Open vSwitch + extension to OpenFlow. </p> </field> <field id="MFF_IN_PORT_OXM" title="OXM Ingress Port"> <p> - OpenFlow 1.1 and later use a 32-bit port number, so this field - supplies a 32-bit view of the ingress port. Current versions of - Open vSwitch support only a 16-bit range of ports: + OpenFlow 1.1 and later use a 32-bit port number, so this field + supplies a 32-bit view of the ingress port. Current versions of + Open vSwitch support only a 16-bit range of ports: </p> <ul> - <li> - OpenFlow 1.0 ports <code>0x0000</code> to - <code>0xfeff</code>, inclusive, map to OpenFlow 1.1 - port numbers with the same values. - </li> - - <li> - OpenFlow 1.0 ports <code>0xff00</code> to - <code>0xffff</code>, inclusive, map to OpenFlow 1.1 port - numbers <code>0xffffff00</code> to <code>0xffffffff</code>. - </li> - - <li> - OpenFlow 1.1 ports <code>0x0000ff00</code> to - <code>0xfffffeff</code> are not mapped and not supported. - </li> + <li> + OpenFlow 1.0 ports <code>0x0000</code> to + <code>0xfeff</code>, inclusive, map to OpenFlow 1.1 + port numbers with the same values. + </li> + + <li> + OpenFlow 1.0 ports <code>0xff00</code> to + <code>0xffff</code>, inclusive, map to OpenFlow 1.1 port + numbers <code>0xffffff00</code> to <code>0xffffffff</code>. + </li> + + <li> + OpenFlow 1.1 ports <code>0x0000ff00</code> to + <code>0xfffffeff</code> are not mapped and not supported. + </li> </ul> <p> - <ref field="in_port"/> and <ref field="in_port_oxm"/> are two views of - the same information, so all of the comments on <ref field="in_port"/> - apply to <ref field="in_port_oxm"/> too. Modifying <ref - field="in_port"/> changes <ref field="in_port_oxm"/>, and vice versa. + <ref field="in_port"/> and <ref field="in_port_oxm"/> are two views of + the same information, so all of the comments on <ref field="in_port"/> + apply to <ref field="in_port_oxm"/> too. Modifying <ref + field="in_port"/> changes <ref field="in_port_oxm"/>, and vice versa. </p> <p> - Setting <ref field="in_port_oxm"/> to an unsupported value yields - unspecified behavior. + Setting <ref field="in_port_oxm"/> to an unsupported value yields + unspecified behavior. </p> </field> <field id="MFF_SKB_PRIORITY" title="Output Queue"> <p> - <b>Future Directions:</b> Open vSwitch implements the output queue as a - field, but does not currently expose it through OXM or NXM for matching - purposes. If this turns out to be a useful feature, it could be - implemented in future versions. Only the <code>set_queue</code>, - <code>enqueue</code>, and <code>pop_queue</code> actions currently - influence the output queue. + <b>Future Directions:</b> Open vSwitch implements the output queue as a + field, but does not currently expose it through OXM or NXM for matching + purposes. If this turns out to be a useful feature, it could be + implemented in future versions. Only the <code>set_queue</code>, + <code>enqueue</code>, and <code>pop_queue</code> actions currently + influence the output queue. </p> <p> - This field influences how packets in the flow will be queued, - for quality of service (QoS) purposes, when they egress the - switch. Its range of meaningful values, and their meanings, - varies greatly from one OpenFlow implementation to another. - Even within a single implementation, there is no guarantee - that all OpenFlow ports have the same queues configured or - that all OpenFlow ports in an implementation can be configured - the same way queue-wise. + This field influences how packets in the flow will be queued, + for quality of service (QoS) purposes, when they egress the + switch. Its range of meaningful values, and their meanings, + varies greatly from one OpenFlow implementation to another. + Even within a single implementation, there is no guarantee + that all OpenFlow ports have the same queues configured or + that all OpenFlow ports in an implementation can be configured + the same way queue-wise. </p> <p> - Configuring queues on OpenFlow is not well standardized. On - Linux, Open vSwitch supports queue configuration via OVSDB, - specifically the <code>QoS</code> and <code>Queue</code> - tables (see <code>ovs-vswitchd.conf.db(5)</code> for details). - Ports of Open vSwitch to other platforms might require queue - configuration through some separate protocol (such as a CLI). - Even on Linux, Open vSwitch exposes only a fraction of the - kernel's queuing features through OVSDB, so advanced or - unusual uses might require use of separate utilities - (e.g. <code>tc</code>). OpenFlow switches other than Open - vSwitch might use OF-CONFIG or any of the configuration - methods mentioned above. Finally, some OpenFlow switches have - a fixed number of fixed-function queues (e.g. eight queues - with strictly defined priorities) and others do not support - any control over queuing. + Configuring queues on OpenFlow is not well standardized. On + Linux, Open vSwitch supports queue configuration via OVSDB, + specifically the <code>QoS</code> and <code>Queue</code> + tables (see <code>ovs-vswitchd.conf.db(5)</code> for details). + Ports of Open vSwitch to other platforms might require queue + configuration through some separate protocol (such as a CLI). + Even on Linux, Open vSwitch exposes only a fraction of the + kernel's queuing features through OVSDB, so advanced or + unusual uses might require use of separate utilities + (e.g. <code>tc</code>). OpenFlow switches other than Open + vSwitch might use OF-CONFIG or any of the configuration + methods mentioned above. Finally, some OpenFlow switches have + a fixed number of fixed-function queues (e.g. eight queues + with strictly defined priorities) and others do not support + any control over queuing. </p> <p> - The only output queue that all OpenFlow implementations must - support is zero, to identify a default queue, whose properties - are implementation-defined. Outputting a packet to a queue - that does not exist on the output port yields unpredictable - behavior: among the possibilities are that the packet might be - dropped or transmitted with a very high or very low priority. + The only output queue that all OpenFlow implementations must + support is zero, to identify a default queue, whose properties + are implementation-defined. Outputting a packet to a queue + that does not exist on the output port yields unpredictable + behavior: among the possibilities are that the packet might be + dropped or transmitted with a very high or very low priority. </p> <p> - OpenFlow 1.0 only allowed output queues to be specified as part of an - <code>enqueue</code> action that specified both a queue and an output - port. That is, OpenFlow 1.0 treats the queue as an argument to an - action, not as a field. + OpenFlow 1.0 only allowed output queues to be specified as part of an + <code>enqueue</code> action that specified both a queue and an output + port. That is, OpenFlow 1.0 treats the queue as an argument to an + action, not as a field. </p> <p> - To increase flexibility, OpenFlow 1.1 added an action to set the output - queue. This model was carried forward, without change, through - OpenFlow 1.5. + To increase flexibility, OpenFlow 1.1 added an action to set the output + queue. This model was carried forward, without change, through + OpenFlow 1.5. </p> <p> - Open vSwitch implements the native queuing model of each - OpenFlow version it supports. Open vSwitch also includes an - extension for setting the output queue as an action in - OpenFlow 1.0. + Open vSwitch implements the native queuing model of each + OpenFlow version it supports. Open vSwitch also includes an + extension for setting the output queue as an action in + OpenFlow 1.0. </p> <p> - When a packet ingresses into an OpenFlow switch, the output - queue is ordinarily set to 0, indicating the default queue. - However, Open vSwitch supports various ways to forward a - packet from one OpenFlow switch to another within a single - host. In these cases, Open vSwitch maintains the output queue - across the forwarding step. For example: + When a packet ingresses into an OpenFlow switch, the output + queue is ordinarily set to 0, indicating the default queue. + However, Open vSwitch supports various ways to forward a + packet from one OpenFlow switch to another within a single + host. In these cases, Open vSwitch maintains the output queue + across the forwarding step. For example: </p> <ul> - <li> - A hop across an Open vSwitch ``patch port'' (which does not - actually involve queuing) preserves the output queue. - </li> - - <li> - <p> - When a flow sets the output queue then outputs to an - OpenFlow tunnel port, the encapsulation preserves the - output queue. If the kernel TCP/IP stack routes the - encapsulated packet directly to a physical interface, then - that output honors the output queue. Alternatively, if - the kernel routes the encapsulated packet to another Open - vSwitch bridge, then the output queue set previously - becomes the initial output queue on ingress to the second - bridge and will thus be used for further output actions - (unless overridden by a new ``set queue'' action). - </p> - - <p> - (This description reflects the current behavior of Open - vSwitch on Linux. This behavior relies on details of the - Linux TCP/IP stack. It could be difficult to make ports - to other operating systems behave the same way.) - </p> - </li> + <li> + A hop across an Open vSwitch ``patch port'' (which does not + actually involve queuing) preserves the output queue. + </li> + + <li> + <p> + When a flow sets the output queue then outputs to an + OpenFlow tunnel port, the encapsulation preserves the + output queue. If the kernel TCP/IP stack routes the + encapsulated packet directly to a physical interface, then + that output honors the output queue. Alternatively, if + the kernel routes the encapsulated packet to another Open + vSwitch bridge, then the output queue set previously + becomes the initial output queue on ingress to the second + bridge and will thus be used for further output actions + (unless overridden by a new ``set queue'' action). + </p> + + <p> + (This description reflects the current behavior of Open + vSwitch on Linux. This behavior relies on details of the + Linux TCP/IP stack. It could be difficult to make ports + to other operating systems behave the same way.) + </p> + </li> </ul> </field> @@ -2341,31 +2341,31 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </p> <p> - Packet mark is an attempt at a generalization of the - <code>skb_mark</code> concept beyond Linux, at least through more - generic naming. Like <ref field="skb_priority"/>, packet mark is - preserved across forwarding steps within a machine. Unlike <ref - field="skb_priority"/>, packet mark has no direct effect on packet - forwarding: the value set in packet mark does not matter unless some - later OpenFlow table or switch matches on packet mark, or unless the - packet passes through some other kernel subsystem that has been - configured to interpret packet mark in specific ways, e.g. through - <code>iptables</code> configuration mentioned above. + Packet mark is an attempt at a generalization of the + <code>skb_mark</code> concept beyond Linux, at least through more + generic naming. Like <ref field="skb_priority"/>, packet mark is + preserved across forwarding steps within a machine. Unlike <ref + field="skb_priority"/>, packet mark has no direct effect on packet + forwarding: the value set in packet mark does not matter unless some + later OpenFlow table or switch matches on packet mark, or unless the + packet passes through some other kernel subsystem that has been + configured to interpret packet mark in specific ways, e.g. through + <code>iptables</code> configuration mentioned above. </p> <p> - Preserving packet mark across kernel forwarding steps relies - heavily on kernel support, which ports to non-Linux operating - systems may not have. Regardless of operating system support, - Open vSwitch supports packet mark within a single bridge and - across patch ports. + Preserving packet mark across kernel forwarding steps relies + heavily on kernel support, which ports to non-Linux operating + systems may not have. Regardless of operating system support, + Open vSwitch supports packet mark within a single bridge and + across patch ports. </p> <p> - The value of packet mark when a packet ingresses into the - first Open vSwich bridge is typically zero, but it could be - nonzero if its value was previously set by some kernel - subsystem. + The value of packet mark when a packet ingresses into the + first Open vSwich bridge is typically zero, but it could be + nonzero if its value was previously set by some kernel + subsystem. </p> </field> @@ -2395,11 +2395,11 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </p> <diagram> - <header name="Packet type"> - <bits name="ns" above="16" width=".75"/> - <bits name="ns_type" above="16" width=".75"/> - </header> - <dots/> + <header name="Packet type"> + <bits name="ns" above="16" width=".75"/> + <bits name="ns_type" above="16" width=".75"/> + </header> + <dots/> </diagram> <p> @@ -2443,18 +2443,18 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> - </header> - <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" width="0.4"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> + </header> + <header name="IPv4"> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" width="0.4"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4"/> + </header> + <dots/> </diagram> <p> @@ -2463,13 +2463,13 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </p> <diagram> - <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" width="0.4"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4"/> - </header> - <dots/> + <header name="IPv4"> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" width="0.4"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4"/> + </header> + <dots/> </diagram> <p> @@ -2796,23 +2796,23 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <field id="MFF_METADATA" title="OpenFlow Metadata"> <p> - This field is the oldest standardized OpenFlow register field, - introduced in OpenFlow 1.1. It was introduced to model the limited - number of user-defined bits that some ASIC-based switches can carry - through their pipelines. Because of hardware limitations, OpenFlow - allows switches to support writing and masking only an - implementation-defined subset of bits, even no bits at all. The Open - vSwitch software switch always supports all 64 bits, but of course an - Open vSwitch port to an ASIC would have the same restriction as the - ASIC itself. + This field is the oldest standardized OpenFlow register field, + introduced in OpenFlow 1.1. It was introduced to model the limited + number of user-defined bits that some ASIC-based switches can carry + through their pipelines. Because of hardware limitations, OpenFlow + allows switches to support writing and masking only an + implementation-defined subset of bits, even no bits at all. The Open + vSwitch software switch always supports all 64 bits, but of course an + Open vSwitch port to an ASIC would have the same restriction as the + ASIC itself. </p> <p> - This field has an OXM code point, but OpenFlow 1.4 and earlier allow it - to be modified only with a specialized instruction, not with a - ``set-field'' action. OpenFlow 1.5 removes this restriction. Open - vSwitch does not enforce this restriction, regardless of OpenFlow - version. + This field has an OXM code point, but OpenFlow 1.4 and earlier allow it + to be modified only with a specialized instruction, not with a + ``set-field'' action. OpenFlow 1.5 removes this restriction. Open + vSwitch does not enforce this restriction, regardless of OpenFlow + version. </p> </field> @@ -2910,27 +2910,27 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width=".75"/> - <bits name="src" above="48" width=".75" fill="yes"/> - <bits name="type" above="16" width="0.4"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width=".75"/> + <bits name="src" above="48" width=".75" fill="yes"/> + <bits name="type" above="16" width="0.4"/> + </header> + <dots/> </diagram> </field> <field id="MFF_ETH_DST" title="Ethernet Destination"> <p> - The Ethernet destination address: + The Ethernet destination address: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width=".75" fill="yes"/> - <bits name="src" above="48" width=".75"/> - <bits name="type" above="16" width="0.4"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width=".75" fill="yes"/> + <bits name="src" above="48" width=".75"/> + <bits name="type" above="16" width="0.4"/> + </header> + <dots/> </diagram> <p> @@ -2969,108 +2969,108 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <field id="MFF_ETH_TYPE" title="Ethernet Type"> <p> - The most commonly seen Ethernet frames today use a format - called ``Ethernet II,'' in which the last two bytes of the - Ethernet header specify the Ethertype. For such a frame, this - field is copied from those bytes of the header, like so: + The most commonly seen Ethernet frames today use a format + called ``Ethernet II,'' in which the last two bytes of the + Ethernet header specify the Ethertype. For such a frame, this + field is copied from those bytes of the header, like so: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width=".75"/> - <bits name="src" above="48" width=".75"/> - <bits name="type" above="16" below="\[>=]0x600" width="0.4" fill="yes"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width=".75"/> + <bits name="src" above="48" width=".75"/> + <bits name="type" above="16" below="\[>=]0x600" width="0.4" fill="yes"/> + </header> + <dots/> </diagram> <p> - Every Ethernet type has a value 0x600 (1,536) or greater. - When the last two bytes of the Ethernet header have a value - too small to be an Ethernet type, then the value found there - is the total length of the frame in bytes, excluding the - Ethernet header. An 802.2 LLC header typically follows the - Ethernet header. OpenFlow and Open vSwitch only support LLC - headers with DSAP and SSAP <code>0xaa</code> and control byte - <code>0x03</code>, which indicate that a SNAP header follows - the LLC header. In turn, OpenFlow and Open vSwitch only - support a SNAP header with organization <code>0x000000</code>. - In such a case, this field is copied from the type field in - the SNAP header, like this: + Every Ethernet type has a value 0x600 (1,536) or greater. + When the last two bytes of the Ethernet header have a value + too small to be an Ethernet type, then the value found there + is the total length of the frame in bytes, excluding the + Ethernet header. An 802.2 LLC header typically follows the + Ethernet header. OpenFlow and Open vSwitch only support LLC + headers with DSAP and SSAP <code>0xaa</code> and control byte + <code>0x03</code>, which indicate that a SNAP header follows + the LLC header. In turn, OpenFlow and Open vSwitch only + support a SNAP header with organization <code>0x000000</code>. + In such a case, this field is copied from the type field in + the SNAP header, like this: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width=".75"/> - <bits name="src" above="48" width=".75"/> - <bits name="type" above="16" below="<0x600" width="0.4"/> - </header> - <header name="LLC"> - <bits name="DSAP" above="8" below="0xaa" width=".4"/> - <bits name="SSAP" above="8" below="0xaa" width=".4"/> - <bits name="cntl" above="8" below="0x03" width=".4"/> - </header> - <header name="SNAP"> - <bits name="org" above="24" below="0x000000" width=".75"/> - <bits name="type" above="16" below="\[>=]0x600" width=".4" fill="yes"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width=".75"/> + <bits name="src" above="48" width=".75"/> + <bits name="type" above="16" below="<0x600" width="0.4"/> + </header> + <header name="LLC"> + <bits name="DSAP" above="8" below="0xaa" width=".4"/> + <bits name="SSAP" above="8" below="0xaa" width=".4"/> + <bits name="cntl" above="8" below="0x03" width=".4"/> + </header> + <header name="SNAP"> + <bits name="org" above="24" below="0x000000" width=".75"/> + <bits name="type" above="16" below="\[>=]0x600" width=".4" fill="yes"/> + </header> + <dots/> </diagram> <p> - When an 802.1Q header is inserted after the Ethernet source - and destination, this field is populated with the encapsulated - Ethertype, not the 802.1Q Ethertype. With an Ethernet II - inner frame, the result looks like this: + When an 802.1Q header is inserted after the Ethernet source + and destination, this field is populated with the encapsulated + Ethertype, not the 802.1Q Ethertype. With an Ethernet II + inner frame, the result looks like this: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width=".75"/> - <bits name="src" above="48" width=".75"/> - </header> - <header name="802.1Q"> - <bits name="TPID" above="16" below="0x8100" width=".4"/> - <bits name="TCI" above="16" width=".4"/> - </header> - <header name="Ethertype"> - <bits name="type" above="16" below="\[>=]0x600" width=".4" fill="yes"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width=".75"/> + <bits name="src" above="48" width=".75"/> + </header> + <header name="802.1Q"> + <bits name="TPID" above="16" below="0x8100" width=".4"/> + <bits name="TCI" above="16" width=".4"/> + </header> + <header name="Ethertype"> + <bits name="type" above="16" below="\[>=]0x600" width=".4" fill="yes"/> + </header> + <dots/> </diagram> <p> - LLC and SNAP encapsulation look like this with an 802.1Q header: + LLC and SNAP encapsulation look like this with an 802.1Q header: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width=".75"/> - <bits name="src" above="48" width=".75"/> - </header> - <header name="802.1Q"> - <bits name="TPID" above="16" below="0x8100" width=".4"/> - <bits name="TCI" above="16" width=".4"/> - </header> - <header name="Ethertype"> - <bits name="type" above="16" below="<0x600" width="0.4"/> - </header> - <header name="LLC"> - <bits name="DSAP" above="8" below="0xaa" width=".4"/> - <bits name="SSAP" above="8" below="0xaa" width=".4"/> - <bits name="cntl" above="8" below="0x03" width=".4"/> - </header> - <header name="SNAP"> - <bits name="org" above="24" below="0x000000" width=".75"/> - <bits name="type" above="16" below="\[>=]0x600" width=".4" fill="yes"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width=".75"/> + <bits name="src" above="48" width=".75"/> + </header> + <header name="802.1Q"> + <bits name="TPID" above="16" below="0x8100" width=".4"/> + <bits name="TCI" above="16" width=".4"/> + </header> + <header name="Ethertype"> + <bits name="type" above="16" below="<0x600" width="0.4"/> + </header> + <header name="LLC"> + <bits name="DSAP" above="8" below="0xaa" width=".4"/> + <bits name="SSAP" above="8" below="0xaa" width=".4"/> + <bits name="cntl" above="8" below="0x03" width=".4"/> + </header> + <header name="SNAP"> + <bits name="org" above="24" below="0x000000" width=".75"/> + <bits name="type" above="16" below="\[>=]0x600" width=".4" fill="yes"/> + </header> + <dots/> </diagram> <p> - When a packet doesn't match any of the header formats described - above, Open vSwitch and OpenFlow set this field to - <code>0x5ff</code> (<code>OFP_DL_TYPE_NOT_ETH_TYPE</code>). + When a packet doesn't match any of the header formats described + above, Open vSwitch and OpenFlow set this field to + <code>0x5ff</code> (<code>OFP_DL_TYPE_NOT_ETH_TYPE</code>). </p> </field> </group> @@ -3091,13 +3091,13 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <diagram> <header name="TPID"> - <bits name="Ethertype" above="16" below="0x8100" width="1.8"/> + <bits name="Ethertype" above="16" below="0x8100" width="1.8"/> </header> <nospace/> <header name="TCI"> - <bits name="PCP" above="3" width=".6"/> - <bits name="CFI" above="1" below="0" width=".3"/> - <bits name="VID" above="12" width=".9"/> + <bits name="PCP" above="3" width=".6"/> + <bits name="CFI" above="1" below="0" width=".3"/> + <bits name="VID" above="12" width=".9"/> </header> </diagram> @@ -3123,28 +3123,28 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <ul> <li> - <dfn>PCP</dfn> (Priority Control Point), is a 3-bit 802.1p - <dfn>priority</dfn>. The lowest priority is value 1, the - second-lowest is value 0, and priority increases from 2 up to - highest priority 7. + <dfn>PCP</dfn> (Priority Control Point), is a 3-bit 802.1p + <dfn>priority</dfn>. The lowest priority is value 1, the + second-lowest is value 0, and priority increases from 2 up to + highest priority 7. </li> <li> <p> - <dfn>CFI</dfn> (Canonical Format Indicator), is a 1-bit field. On an - Ethernet network, its value is always 0. This led to it later being - repurposed under the name <dfn>DEI</dfn> (Drop Eligibility - Indicator). By either name, OpenFlow and Open vSwitch don't provide - any way to match or set this bit. + <dfn>CFI</dfn> (Canonical Format Indicator), is a 1-bit field. On an + Ethernet network, its value is always 0. This led to it later being + repurposed under the name <dfn>DEI</dfn> (Drop Eligibility + Indicator). By either name, OpenFlow and Open vSwitch don't provide + any way to match or set this bit. </p> </li> <li> - <dfn>VID</dfn> (VLAN IDentifier), is a 12-bit VLAN. If the - VID is 0, then the frame is not part of a VLAN. In that case, - the VLAN header is called a <dfn>priority tag</dfn> because it - is only meaningful for assigning the frame a priority. VID - <code>0xfff</code> (4,095) is reserved. + <dfn>VID</dfn> (VLAN IDentifier), is a 12-bit VLAN. If the + VID is 0, then the frame is not part of a VLAN. In that case, + the VLAN header is called a <dfn>priority tag</dfn> because it + is only meaningful for assigning the frame a priority. VID + <code>0xfff</code> (4,095) is reserved. </li> </ul> @@ -3190,9 +3190,9 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <ul> <li> - When both <code>dl_vlan</code> and <code>dl_vlan_pcp</code> are - wildcarded, the flow matches packets without an 802.1Q header or - with any 802.1Q header. + When both <code>dl_vlan</code> and <code>dl_vlan_pcp</code> are + wildcarded, the flow matches packets without an 802.1Q header or + with any 802.1Q header. </li> <li> @@ -3204,27 +3204,27 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </li> <li> - <p> - Otherwise, the flow matches only packets with an 802.1Q - header. If <code>dl_vlan</code> is not wildcarded, then the - flow only matches packets with the VLAN ID specified in - <code>dl_vlan</code>'s low 12 bits. If - <code>dl_vlan_pcp</code> is not wildcarded, then the flow - only matches packets with the priority specified in - <code>dl_vlan_pcp</code>'s low 3 bits. - </p> - - <p> - OpenFlow does not specify how to interpret the high 4 bits of - <code>dl_vlan</code> or the high 5 bits of <code>dl_vlan_pcp</code>. - Open vSwitch ignores them. - </p> + <p> + Otherwise, the flow matches only packets with an 802.1Q + header. If <code>dl_vlan</code> is not wildcarded, then the + flow only matches packets with the VLAN ID specified in + <code>dl_vlan</code>'s low 12 bits. If + <code>dl_vlan_pcp</code> is not wildcarded, then the flow + only matches packets with the priority specified in + <code>dl_vlan_pcp</code>'s low 3 bits. + </p> + + <p> + OpenFlow does not specify how to interpret the high 4 bits of + <code>dl_vlan</code> or the high 5 bits of <code>dl_vlan_pcp</code>. + Open vSwitch ignores them. + </p> </li> </ul> <field id="MFF_DL_VLAN" title="OpenFlow 1.0 VLAN ID" hidden="yes"/> <field id="MFF_DL_VLAN_PCP" title="OpenFlow 1.0 VLAN Priority" - hidden="yes"/> + hidden="yes"/> <h2>OpenFlow 1.1 VLAN Fields</h2> @@ -3257,88 +3257,88 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <field id="MFF_VLAN_VID" title="OpenFlow 1.2+ VLAN ID"> <p> - The OpenFlow standard describes this field as consisting of - ``12+1'' bits. On ingress, its value is 0 if no 802.1Q header - is present, and otherwise it holds the VLAN VID in its least - significant 12 bits, with bit 12 (<code>0x1000</code> aka - <code>OFPVID_PRESENT</code>) also set to 1. The three most - significant bits are always zero: + The OpenFlow standard describes this field as consisting of + ``12+1'' bits. On ingress, its value is 0 if no 802.1Q header + is present, and otherwise it holds the VLAN VID in its least + significant 12 bits, with bit 12 (<code>0x1000</code> aka + <code>OFPVID_PRESENT</code>) also set to 1. The three most + significant bits are always zero: </p> <diagram> - <header name="OXM_OF_VLAN_VID"> - <bits name="" above="3" below="0" width=".6"/> - <bits name="P" above="1" width=".1"/> - <bits name="VLAN ID" above="12" width=".9"/> - </header> + <header name="OXM_OF_VLAN_VID"> + <bits name="" above="3" below="0" width=".6"/> + <bits name="P" above="1" width=".1"/> + <bits name="VLAN ID" above="12" width=".9"/> + </header> </diagram> <p> - As a consequence of this field's format, one may use it to match the - VLAN ID in all of the ways available with the OpenFlow 1.0 and 1.1 - formats, and a few new ways: + As a consequence of this field's format, one may use it to match the + VLAN ID in all of the ways available with the OpenFlow 1.0 and 1.1 + formats, and a few new ways: </p> <dl> - <dt>Fully wildcarded</dt> - <dd> - Matches any packet, that is, one without an 802.1Q header or - with an 802.1Q header with any TCI value. - </dd> - - <dt> - Value <code>0x0000</code> (<code>OFPVID_NONE</code>), mask - <code>0xffff</code> (or no mask) - </dt> - <dd> - Matches only packets without an 802.1Q header. - </dd> - - <dt> - Value <code>0x1000</code>, mask <code>0x1000</code> - </dt> - <dd> - Matches any packet with an 802.1Q header, regardless of VLAN - ID. - </dd> - - <dt> - Value <code>0x1009</code>, mask <code>0xffff</code> (or no mask) - </dt> - <dd> - Match only packets with an 802.1Q header with VLAN ID 9. - </dd> - - <dt>Value <code>0x1001</code>, mask <code>0x1001</code></dt> - <dd> - Matches only packets that have an 802.1Q header with an - odd-numbered VLAN ID. (This is just an example; one can - match on any desired VLAN ID bit pattern.) - </dd> + <dt>Fully wildcarded</dt> + <dd> + Matches any packet, that is, one without an 802.1Q header or + with an 802.1Q header with any TCI value. + </dd> + + <dt> + Value <code>0x0000</code> (<code>OFPVID_NONE</code>), mask + <code>0xffff</code> (or no mask) + </dt> + <dd> + Matches only packets without an 802.1Q header. + </dd> + + <dt> + Value <code>0x1000</code>, mask <code>0x1000</code> + </dt> + <dd> + Matches any packet with an 802.1Q header, regardless of VLAN + ID. + </dd> + + <dt> + Value <code>0x1009</code>, mask <code>0xffff</code> (or no mask) + </dt> + <dd> + Match only packets with an 802.1Q header with VLAN ID 9. + </dd> + + <dt>Value <code>0x1001</code>, mask <code>0x1001</code></dt> + <dd> + Matches only packets that have an 802.1Q header with an + odd-numbered VLAN ID. (This is just an example; one can + match on any desired VLAN ID bit pattern.) + </dd> </dl> </field> <field id="MFF_VLAN_PCP" title="OpenFlow 1.2+ VLAN Priority"> <p> - The 3 least significant bits may be used to match the PCP bits - in an 802.1Q header. Other bits are always zero: + The 3 least significant bits may be used to match the PCP bits + in an 802.1Q header. Other bits are always zero: </p> <diagram> - <header name="OXM_OF_VLAN_VID"> - <bits name="zero" above="5" below="0" width="1.0"/> - <bits name="PCP" above="3" width=".6"/> - </header> + <header name="OXM_OF_VLAN_VID"> + <bits name="zero" above="5" below="0" width="1.0"/> + <bits name="PCP" above="3" width=".6"/> + </header> </diagram> <p> - This field may only be used when <ref field="vlan_vid"/> is not - wildcarded and does not exact match on 0 (which only matches - when there is no 802.1Q header). + This field may only be used when <ref field="vlan_vid"/> is not + wildcarded and does not exact match on 0 (which only matches + when there is no 802.1Q header). </p> <p> - See <cite>VLAN Comparison Chart</cite>, below, for some examples. + See <cite>VLAN Comparison Chart</cite>, below, for some examples. </p> </field> @@ -3352,19 +3352,19 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <field id="MFF_VLAN_TCI" title="VLAN TCI"> <p> - For a packet without an 802.1Q header, this field is zero. For a - packet with an 802.1Q header, this field is the TCI with the bit in - CFI's position (marked <code>P</code> for ``present'' below) forced to - 1. Thus, for a packet in VLAN 9 with priority 7, it has the value - <code>0xf009</code>: + For a packet without an 802.1Q header, this field is zero. For a + packet with an 802.1Q header, this field is the TCI with the bit in + CFI's position (marked <code>P</code> for ``present'' below) forced to + 1. Thus, for a packet in VLAN 9 with priority 7, it has the value + <code>0xf009</code>: </p> <diagram> - <header name="NXM_VLAN_TCI"> - <bits name="PCP" above="3" below="7" width=".6"/> - <bits name="P" above="1" below="1" width=".2"/> - <bits name="VID" above="12" below="9" width=".9"/> - </header> + <header name="NXM_VLAN_TCI"> + <bits name="PCP" above="3" below="7" width=".6"/> + <bits name="P" above="1" below="1" width=".2"/> + <bits name="VID" above="12" below="9" width=".9"/> + </header> </diagram> <p> @@ -3417,7 +3417,7 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) </dl> <p> - See <cite>VLAN Comparison Chart</cite>, below, for more examples. + See <cite>VLAN Comparison Chart</cite>, below, for more examples. </p> </field> @@ -3431,22 +3431,22 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123) <tbl> r r r r r. -Criteria OpenFlow 1.0 OpenFlow 1.1 OpenFlow 1.2+ NXM -\_ \_ \_ \_ \_ -[1] \fL????\fR/\fL1\fR,\fL??\fR/\fL?\fR \fL????\fR/\fL1\fR,\fL??\fR/\fL?\fR \fL0000\fR/\fL0000\fR,\fL--\fR \fL0000\fR/\fL0000\fR -[2] \fLffff\fR/\fL0\fR,\fL??\fR/\fL?\fR \fLffff\fR/\fL0\fR,\fL??\fR/\fL?\fR \fL0000\fR/\fLffff\fR,\fL--\fR \fL0000\fR/\fLffff\fR -[3] \fL0xxx\fR/\fL0\fR,\fL??\fR/\fL1\fR \fL0xxx\fR/\fL0\fR,\fL??\fR/\fL1\fR \fL1xxx\fR/\fLffff\fR,\fL--\fR \fL1xxx\fR/\fL1fff\fR -[4] \fL????\fR/\fL1\fR,\fL0y\fR/\fL0\fR \fLfffe\fR/\fL0\fR,\fL0y\fR/\fL0\fR \fL1000\fR/\fL1000\fR,\fL0y\fR \fLz000\fR/\fLf000\fR -[5] \fL0xxx\fR/\fL0\fR,\fL0y\fR/\fL0\fR \fL0xxx\fR/\fL0\fR,\fL0y\fR/\fL0\fR \fL1xxx\fR/\fLffff\fR,\fL0y\fR \fLzxxx\fR/\fLffff\fR +Criteria OpenFlow 1.0 OpenFlow 1.1 OpenFlow 1.2+ NXM +\_ \_ \_ \_ \_ +[1] \fL????\fR/\fL1\fR,\fL??\fR/\fL?\fR \fL????\fR/\fL1\fR,\fL??\fR/\fL?\fR \fL0000\fR/\fL0000\fR,\fL--\fR \fL0000\fR/\fL0000\fR +[2] \fLffff\fR/\fL0\fR,\fL??\fR/\fL?\fR \fLffff\fR/\fL0\fR,\fL??\fR/\fL?\fR \fL0000\fR/\fLffff\fR,\fL--\fR \fL0000\fR/\fLffff\fR +[3] \fL0xxx\fR/\fL0\fR,\fL??\fR/\fL1\fR \fL0xxx\fR/\fL0\fR,\fL??\fR/\fL1\fR \fL1xxx\fR/\fLffff\fR,\fL--\fR \fL1xxx\fR/\fL1fff\fR +[4] \fL????\fR/\fL1\fR,\fL0y\fR/\fL0\fR \fLfffe\fR/\fL0\fR,\fL0y\fR/\fL0\fR \fL1000\fR/\fL1000\fR,\fL0y\fR \fLz000\fR/\fLf000\fR +[5] \fL0xxx\fR/\fL0\fR,\fL0y\fR/\fL0\fR \fL0xxx\fR/\fL0\fR,\fL0y\fR/\fL0\fR \fL1xxx\fR/\fLffff\fR,\fL0y\fR \fLzxxx\fR/\fLffff\fR .T& r r c c r. -[6] (none) (none) \fL1001\fR/\fL1001\fR,\fL--\fR \fL1001\fR/\fL1001\fR +[6] (none) (none) \fL1001\fR/\fL1001\fR,\fL--\fR \fL1001\fR/\fL1001\fR .T& r r c c c. -[7] (none) (none) (none) \fL3000\fR/\fL3000\fR -[8] (none) (none) (none) \fL0000\fR/\fL0fff\fR -[9] (none) (none) (none) \fL0000\fR/\fLf000\fR -[10] (none) (none) (none) \fL0000\fR/\fLefff\fR +[7] (none) (none) (none) \fL3000\fR/\fL3000\fR +[8] (none) (none) (none) \fL0000\fR/\fL0fff\fR +[9] (none) (none) (none) \fL0000\fR/\fLf000\fR +[10] (none) (none) (none) \fL0000\fR/\fLefff\fR </tbl> <p> @@ -3461,32 +3461,32 @@ r r c c c. <dt>OpenFlow 1.0</dt> <dt>OpenFlow 1.1</dt> <dd> - <literal>wwww/x,yy/z</literal> means VLAN ID match value - <literal>wwww</literal> with wildcard bit <literal>x</literal> - and VLAN PCP match value <literal>yy</literal> with wildcard - bit <literal>z</literal>. <literal>?</literal> means that the - given bits are ignored (and conventionally - <literal>0</literal> for <literal>wwww</literal> or - <literal>yy</literal>, conventionally <literal>1</literal> for - <literal>x</literal> or <literal>z</literal>). ``(none)'' - means that OpenFlow 1.0 (or 1.1) cannot match with these - criteria. + <literal>wwww/x,yy/z</literal> means VLAN ID match value + <literal>wwww</literal> with wildcard bit <literal>x</literal> + and VLAN PCP match value <literal>yy</literal> with wildcard + bit <literal>z</literal>. <literal>?</literal> means that the + given bits are ignored (and conventionally + <literal>0</literal> for <literal>wwww</literal> or + <literal>yy</literal>, conventionally <literal>1</literal> for + <literal>x</literal> or <literal>z</literal>). ``(none)'' + means that OpenFlow 1.0 (or 1.1) cannot match with these + criteria. </dd> <dt>OpenFlow 1.2+</dt> <dd> - <literal>xxxx/yyyy,zz</literal> means <ref field="vlan_vid"/> with - value <literal>xxxx</literal> and mask <literal>yyyy</literal>, and - <ref field="vlan_pcp"/> (which is not maskable) with value - <literal>zz</literal>. <literal>--</literal> means that <ref - field="vlan_pcp"/> is omitted. ``(none)'' means that OpenFlow 1.2 - cannot match with these criteria. + <literal>xxxx/yyyy,zz</literal> means <ref field="vlan_vid"/> with + value <literal>xxxx</literal> and mask <literal>yyyy</literal>, and + <ref field="vlan_pcp"/> (which is not maskable) with value + <literal>zz</literal>. <literal>--</literal> means that <ref + field="vlan_pcp"/> is omitted. ``(none)'' means that OpenFlow 1.2 + cannot match with these criteria. </dd> <dt>NXM</dt> <dd> - <literal>xxxx/yyyy</literal> means <ref field="vlan_tci"/> with value - <literal>xxxx</literal> and mask <literal>yyyy</literal>. + <literal>xxxx/yyyy</literal> means <ref field="vlan_tci"/> with value + <literal>xxxx</literal> and mask <literal>yyyy</literal>. </dd> </dl> @@ -3497,111 +3497,111 @@ r r c c c. <dl> <dt>[1]</dt> <dd> - Matches any packet, that is, one without an 802.1Q header or - with an 802.1Q header with any TCI value. + Matches any packet, that is, one without an 802.1Q header or + with an 802.1Q header with any TCI value. </dd> <dt>[2]</dt> <dd> - <p> - Matches only packets without an 802.1Q header. - </p> - - <p> - OpenFlow 1.0 doesn't define the behavior if <ref field="dl_vlan"/> is - set to <code>0xffff</code> and <ref field="dl_vlan_pcp"/> is not - wildcarded. (Open vSwitch always ignores <ref field="dl_vlan_pcp"/> - when <ref field="dl_vlan"/> is set to <code>0xffff</code>.) - </p> - - <p> - OpenFlow 1.1 says explicitly to ignore <ref field="dl_vlan_pcp"/> - when <ref field="dl_vlan"/> is set to <code>0xffff</code>. - </p> - - <p> - OpenFlow 1.2 doesn't say how to interpret a match with <ref - field="vlan_vid"/> value 0 and a mask with - <code>OFPVID_PRESENT</code> (<code>0x1000</code>) set to 1 and some - other bits in the mask set to 1 also. Open vSwitch interprets it the - same way as a mask of <code>0x1000</code>. - </p> - - <p> - Any NXM match with <ref field="vlan_tci"/> value 0 and the CFI bit - set to 1 in the mask is equivalent to the one listed in the table. - </p> + <p> + Matches only packets without an 802.1Q header. + </p> + + <p> + OpenFlow 1.0 doesn't define the behavior if <ref field="dl_vlan"/> is + set to <code>0xffff</code> and <ref field="dl_vlan_pcp"/> is not + wildcarded. (Open vSwitch always ignores <ref field="dl_vlan_pcp"/> + when <ref field="dl_vlan"/> is set to <code>0xffff</code>.) + </p> + + <p> + OpenFlow 1.1 says explicitly to ignore <ref field="dl_vlan_pcp"/> + when <ref field="dl_vlan"/> is set to <code>0xffff</code>. + </p> + + <p> + OpenFlow 1.2 doesn't say how to interpret a match with <ref + field="vlan_vid"/> value 0 and a mask with + <code>OFPVID_PRESENT</code> (<code>0x1000</code>) set to 1 and some + other bits in the mask set to 1 also. Open vSwitch interprets it the + same way as a mask of <code>0x1000</code>. + </p> + + <p> + Any NXM match with <ref field="vlan_tci"/> value 0 and the CFI bit + set to 1 in the mask is equivalent to the one listed in the table. + </p> </dd> <dt>[3]</dt> <dd> - Matches only packets that have an 802.1Q header with VID - <literal>xxx</literal> (and any PCP). + Matches only packets that have an 802.1Q header with VID + <literal>xxx</literal> (and any PCP). </dd> <dt>[4]</dt> <dd> - <p> - Matches only packets that have an 802.1Q header with PCP - <literal>y</literal> (and any VID). - </p> - - <p> - OpenFlow 1.0 doesn't clearly define the behavior for this - case. Open vSwitch implements it this way. - </p> - - <p> - In the NXM value, <literal>z</literal> equals - (<literal>y</literal> << 1) | 1. - </p> + <p> + Matches only packets that have an 802.1Q header with PCP + <literal>y</literal> (and any VID). + </p> + + <p> + OpenFlow 1.0 doesn't clearly define the behavior for this + case. Open vSwitch implements it this way. + </p> + + <p> + In the NXM value, <literal>z</literal> equals + (<literal>y</literal> << 1) | 1. + </p> </dd> <dt>[5]</dt> <dd> - <p> - Matches only packets that have an 802.1Q header with VID - <literal>xxx</literal> and PCP <literal>y</literal>. - </p> - - <p> - In the NXM value, <literal>z</literal> equals - (<literal>y</literal> << 1) | 1. - </p> + <p> + Matches only packets that have an 802.1Q header with VID + <literal>xxx</literal> and PCP <literal>y</literal>. + </p> + + <p> + In the NXM value, <literal>z</literal> equals + (<literal>y</literal> << 1) | 1. + </p> </dd> <dt>[6]</dt> <dd> - Matches only packets that have an 802.1Q header with an - odd-numbered VID (and any PCP). Only possible with OpenFlow - 1.2 and NXM. (This is just an example; one can match on any - desired VID bit pattern.) + Matches only packets that have an 802.1Q header with an + odd-numbered VID (and any PCP). Only possible with OpenFlow + 1.2 and NXM. (This is just an example; one can match on any + desired VID bit pattern.) </dd> <dt>[7]</dt> <dd> - Matches only packets that have an 802.1Q header with an - odd-numbered PCP (and any VID). Only possible with NXM. - (This is just an example; one can match on any desired VID bit - pattern.) + Matches only packets that have an 802.1Q header with an + odd-numbered PCP (and any VID). Only possible with NXM. + (This is just an example; one can match on any desired VID bit + pattern.) </dd> <dt>[8]</dt> <dd> - Matches packets with no 802.1Q header or with an 802.1Q header - with a VID of 0. Only possible with NXM. + Matches packets with no 802.1Q header or with an 802.1Q header + with a VID of 0. Only possible with NXM. </dd> <dt>[9]</dt> <dd> - Matches packets with no 802.1Q header or with an 802.1Q header - with a PCP of 0. Only possible with NXM. + Matches packets with no 802.1Q header or with an 802.1Q header + with a PCP of 0. Only possible with NXM. </dd> <dt>[10]</dt> <dd> - Matches packets with no 802.1Q header or with an 802.1Q header - with both VID and PCP of 0. Only possible with NXM. + Matches packets with no 802.1Q header or with an 802.1Q header + with both VID and PCP of 0. Only possible with NXM. </dd> </dl> </group> @@ -3625,15 +3625,15 @@ r r c c c. <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.75"/> - <bits name="src" above="48" width="0.75"/> - <bits name="type" above="16" below="0x8847" width="0.4"/> + <bits name="dst" above="48" width="0.75"/> + <bits name="src" above="48" width="0.75"/> + <bits name="type" above="16" below="0x8847" width="0.4"/> </header> <header name="MPLS"> - <bits name="label" above="20" width=".6"/> - <bits name="TC" above="3" width=".3"/> - <bits name="S" above="1" width=".1"/> - <bits name="TTL" above="8" width=".4"/> + <bits name="label" above="20" width=".6"/> + <bits name="TC" above="3" width=".3"/> + <bits name="S" above="1" width=".1"/> + <bits name="TTL" above="8" width=".4"/> </header> <dots/> </diagram> @@ -3645,21 +3645,21 @@ r r c c c. <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width=".75"/> - <bits name="src" above="48" width=".75"/> + <bits name="dst" above="48" width=".75"/> + <bits name="src" above="48" width=".75"/> </header> <header name="802.1Q"> - <bits name="TPID" above="16" below="0x8100" width=".4"/> - <bits name="TCI" above="16" width=".4"/> + <bits name="TPID" above="16" below="0x8100" width=".4"/> + <bits name="TCI" above="16" width=".4"/> </header> <header name="Ethertype"> - <bits name="type" above="16" below="0x8847" width=".4"/> + <bits name="type" above="16" below="0x8847" width=".4"/> </header> <header name="MPLS"> - <bits name="label" above="20" width=".6"/> - <bits name="TC" above="3" width=".3"/> - <bits name="S" above="1" width=".1"/> - <bits name="TTL" above="8" width=".4"/> + <bits name="label" above="20" width=".6"/> + <bits name="TC" above="3" width=".3"/> + <bits name="S" above="1" width=".1"/> + <bits name="TTL" above="8" width=".4"/> </header> <dots/> </diagram> @@ -3671,38 +3671,38 @@ r r c c c. <dl> <dt>Label, 20 bits.</dt> <dd> - An identifier. + An identifier. </dd> <dt>Traffic control (TC), 3 bits.</dt> <dd> - Used for quality of service. + Used for quality of service. </dd> <dt>Bottom of stack (BOS), 1 bit (labeled just ``S'' above).</dt> <dd> - <p> - 0 indicates that another MPLS label follows this one. - </p> - - <p> - 1 indicates that this MPLS label is the last one in the - stack, so that some other protocol follows this one. - </p> + <p> + 0 indicates that another MPLS label follows this one. + </p> + + <p> + 1 indicates that this MPLS label is the last one in the + stack, so that some other protocol follows this one. + </p> </dd> <dt>Time to live (TTL), 8 bits.</dt> <dd> - <p> - Each hop across an MPLS network decrements the TTL by 1. If - it reaches 0, the packet is discarded. - </p> - - <p> - OpenFlow does not make the MPLS TTL available as a match field, but - actions are available to set and decrement the TTL. Open vSwitch 2.6 - and later makes the MPLS TTL available as an extension. - </p> + <p> + Each hop across an MPLS network decrements the TTL by 1. If + it reaches 0, the packet is discarded. + </p> + + <p> + OpenFlow does not make the MPLS TTL available as a match field, but + actions are available to set and decrement the TTL. Open vSwitch 2.6 + and later makes the MPLS TTL available as an extension. + </p> </dd> </dl> @@ -3736,28 +3736,28 @@ r r c c c. <ul> <li> - A few reserved label values do indicate an inner protocol. - Label 0, the ``IPv4 Explicit NULL Label,'' indicates inner - IPv4. Label 2, the ``IPv6 Explicit NULL Label,'' indicates - inner IPv6. + A few reserved label values do indicate an inner protocol. + Label 0, the ``IPv4 Explicit NULL Label,'' indicates inner + IPv4. Label 2, the ``IPv6 Explicit NULL Label,'' indicates + inner IPv6. </li> <li> - Some deployments use a single inner protocol consistently. + Some deployments use a single inner protocol consistently. </li> <li> - In some deployments, the inner protocol must be inferred from - the innermost label. + In some deployments, the inner protocol must be inferred from + the innermost label. </li> <li> - In some deployments, the inner protocol must be inferred from - the innermost label and the encapsulated data, e.g. to - distinguish between inner IPv4 and IPv6 based on whether the - first nibble of the inner protocol data are <code>4</code> or - <code>6</code>. OpenFlow and Open vSwitch do not currently - support these cases. + In some deployments, the inner protocol must be inferred from + the innermost label and the encapsulated data, e.g. to + distinguish between inner IPv4 and IPv6 based on whether the + first nibble of the inner protocol data are <code>4</code> or + <code>6</code>. OpenFlow and Open vSwitch do not currently + support these cases. </li> </ul> @@ -3772,82 +3772,82 @@ r r c c c. <field id="MFF_MPLS_LABEL" title="MPLS Label"> <p> - The least significant 20 bits hold the ``label'' field from - the MPLS label. Other bits are zero: + The least significant 20 bits hold the ``label'' field from + the MPLS label. Other bits are zero: </p> <diagram> - <header name="OXM_OF_MPLS_LABEL"> - <bits name="zero" above="12" below="0" width=".6"/> - <bits name="label" above="20" width="1.0"/> - </header> + <header name="OXM_OF_MPLS_LABEL"> + <bits name="zero" above="12" below="0" width=".6"/> + <bits name="label" above="20" width="1.0"/> + </header> </diagram> <p> - Most label values are available for any use by deployments. - Values under 16 are reserved. + Most label values are available for any use by deployments. + Values under 16 are reserved. </p> </field> <field id="MFF_MPLS_TC" title="MPLS Traffic Class"> <p> - The least significant 3 bits hold the TC field from the MPLS - label. Other bits are zero: + The least significant 3 bits hold the TC field from the MPLS + label. Other bits are zero: </p> <diagram> - <header name="OXM_OF_MPLS_TC"> - <bits name="zero" above="5" below="0" width="1.0"/> - <bits name="TC" above="3" width=".6"/> - </header> + <header name="OXM_OF_MPLS_TC"> + <bits name="zero" above="5" below="0" width="1.0"/> + <bits name="TC" above="3" width=".6"/> + </header> </diagram> <p> - This field is intended for use for Quality of Service (QoS) - and Explicit Congestion Notification purposes, but its - particular interpretation is deployment specific. + This field is intended for use for Quality of Service (QoS) + and Explicit Congestion Notification purposes, but its + particular interpretation is deployment specific. </p> <p> - Before 2009, this field was named EXP and reserved for - experimental use [RFC 5462]. + Before 2009, this field was named EXP and reserved for + experimental use [RFC 5462]. </p> </field> <field id="MFF_MPLS_BOS" title="MPLS Bottom of Stack"> <p> - The least significant bit holds the BOS field from the MPLS - label. Other bits are zero: + The least significant bit holds the BOS field from the MPLS + label. Other bits are zero: </p> <diagram> - <header name="OXM_OF_MPLS_BOS"> - <bits name="zero" above="7" below="0" width="1.3"/> - <bits name="BOS" above="1" width=".3"/> - </header> + <header name="OXM_OF_MPLS_BOS"> + <bits name="zero" above="7" below="0" width="1.3"/> + <bits name="BOS" above="1" width=".3"/> + </header> </diagram> <p> - This field is useful as part of processing a series of incoming MPLS - labels. A flow that includes a <code>pop_mpls</code> action should - generally match on <ref field="mpls_bos"/>: + This field is useful as part of processing a series of incoming MPLS + labels. A flow that includes a <code>pop_mpls</code> action should + generally match on <ref field="mpls_bos"/>: </p> <ul> - <li> - When <ref field="mpls_bos"/> is 1, there is another MPLS label - following this one, so the Ethertype passed to <code>pop_mpls</code> - should be an MPLS Ethertype. For example: <code>table=0, - dl_type=0x8847, mpls_bos=1, actions=pop_mpls:0x8847, - goto_table:1</code> - </li> - - <li> - When <ref field="mpls_bos"/> is 0, this MPLS label is the last one, - so the Ethertype passed to <code>pop_mpls</code> should be a non-MPLS - Ethertype such as IPv4. For example: <code>table=1, dl_type=0x8847, - mpls_bos=0, actions=pop_mpls:0x0800, goto_table:2</code> - </li> + <li> + When <ref field="mpls_bos"/> is 1, there is another MPLS label + following this one, so the Ethertype passed to <code>pop_mpls</code> + should be an MPLS Ethertype. For example: <code>table=0, + dl_type=0x8847, mpls_bos=1, actions=pop_mpls:0x8847, + goto_table:1</code> + </li> + + <li> + When <ref field="mpls_bos"/> is 0, this MPLS label is the last one, + so the Ethertype passed to <code>pop_mpls</code> should be a non-MPLS + Ethertype such as IPv4. For example: <code>table=1, dl_type=0x8847, + mpls_bos=0, actions=pop_mpls:0x0800, goto_table:2</code> + </li> </ul> </field> @@ -3857,9 +3857,9 @@ r r c c c. </p> <diagram> - <header name="NXM_NX_MPLS_TTL"> - <bits name="TTL" above="8" width=".4"/> - </header> + <header name="NXM_NX_MPLS_TTL"> + <bits name="TTL" above="8" width=".4"/> + </header> </diagram> </field> </group> @@ -3878,18 +3878,18 @@ r r c c c. </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> - </header> - <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" width="0.4"/> - <bits name="src" above="32" width="0.4" fill="yes"/> - <bits name="dst" above="32" width="0.4"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> + </header> + <header name="IPv4"> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" width="0.4"/> + <bits name="src" above="32" width="0.4" fill="yes"/> + <bits name="dst" above="32" width="0.4"/> + </header> + <dots/> </diagram> <p> @@ -3904,18 +3904,18 @@ r r c c c. </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> - </header> - <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" width="0.4"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4" fill="yes"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> + </header> + <header name="IPv4"> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" width="0.4"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4" fill="yes"/> + </header> + <dots/> </diagram> <p> @@ -3937,18 +3937,18 @@ r r c c c. </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x86dd" width="0.4"/> - </header> - <header name="IPv6"> - <bits name="..." width="0.4"/> - <bits name="next" above="8" width="0.3"/> - <bits name="src" above="128" width="0.8" fill="yes"/> - <bits name="dst" above="128" width="0.8"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x86dd" width="0.4"/> + </header> + <header name="IPv6"> + <bits name="..." width="0.4"/> + <bits name="next" above="8" width="0.3"/> + <bits name="src" above="128" width="0.8" fill="yes"/> + <bits name="dst" above="128" width="0.8"/> + </header> + <dots/> </diagram> <p> @@ -3961,18 +3961,18 @@ r r c c c. The destination address from the IPv6 header: </p> <diagram> - <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x86dd" width="0.4"/> - </header> - <header name="IPv6"> - <bits name="..." width="0.4"/> - <bits name="next" above="8" width="0.3"/> - <bits name="src" above="128" width="0.8"/> - <bits name="dst" above="128" width="0.8" fill="yes"/> - </header> - <dots/> + <header name="Ethernet"> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x86dd" width="0.4"/> + </header> + <header name="IPv6"> + <bits name="..." width="0.4"/> + <bits name="next" above="8" width="0.3"/> + <bits name="src" above="128" width="0.8"/> + <bits name="dst" above="128" width="0.8" fill="yes"/> + </header> + <dots/> </diagram> <p> @@ -3982,15 +3982,15 @@ r r c c c. </field> <field id="MFF_IPV6_LABEL" title="IPv6 Flow Label"> <p> - The least significant 20 bits hold the flow label field from - the IPv6 header. Other bits are zero: + The least significant 20 bits hold the flow label field from + the IPv6 header. Other bits are zero: </p> <diagram> - <header name="OXM_OF_IPV6_FLABEL"> - <bits name="zero" above="12" below="0" width=".6"/> - <bits name="label" above="20" width="1.0"/> - </header> + <header name="OXM_OF_IPV6_FLABEL"> + <bits name="zero" above="12" below="0" width=".6"/> + <bits name="label" above="20" width="1.0"/> + </header> </diagram> </field> @@ -4067,11 +4067,11 @@ r r c c c. </p> <diagram> - <header name="NXM_NX_IP_FRAG"> - <bits name="zero" above="6" below="0" width=".9"/> - <bits name="later" above="1" width=".3"/> - <bits name="any" above="1" width=".3"/> - </header> + <header name="NXM_NX_IP_FRAG"> + <bits name="zero" above="6" below="0" width=".9"/> + <bits name="later" above="1" width=".3"/> + <bits name="any" above="1" width=".3"/> + </header> </diagram> <p> @@ -4149,8 +4149,8 @@ r r c c c. <diagram> <header name="type of service"> - <bits name="DSCP" above="6" width=".9"/> - <bits name="ECN" above="2" width=".3"/> + <bits name="DSCP" above="6" width=".9"/> + <bits name="ECN" above="2" width=".3"/> </header> </diagram> @@ -4160,10 +4160,10 @@ r r c c c. </p> <diagram> - <header name="NXM_OF_IP_TOS"> - <bits name="DSCP" above="6" width=".9"/> - <bits name="zero" above="2" below="0" width=".3"/> - </header> + <header name="NXM_OF_IP_TOS"> + <bits name="DSCP" above="6" width=".9"/> + <bits name="zero" above="2" below="0" width=".3"/> + </header> </diagram> </field> <field id="MFF_IP_DSCP_SHIFTED" title="IPv4/v6 DSCP (Bits 0-5)"> @@ -4173,10 +4173,10 @@ r r c c c. </p> <diagram> - <header name="OXM_OF_IP_DSCP"> - <bits name="zero" above="2" below="0" width=".3"/> - <bits name="DSCP" above="6" width=".9"/> - </header> + <header name="OXM_OF_IP_DSCP"> + <bits name="zero" above="2" below="0" width=".3"/> + <bits name="DSCP" above="6" width=".9"/> + </header> </diagram> </field> <field id="MFF_IP_ECN" title="IPv4/v6 ECN"> @@ -4185,10 +4185,10 @@ r r c c c. </p> <diagram> - <header name="OXM_OF_IP_ECN"> - <bits name="zero" above="6" below="0" width=".9"/> - <bits name="ECN" above="2" width=".35"/> - </header> + <header name="OXM_OF_IP_ECN"> + <bits name="zero" above="6" below="0" width=".9"/> + <bits name="ECN" above="2" width=".35"/> + </header> </diagram> </field> @@ -4207,20 +4207,20 @@ r r c c c. <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x806" width="0.4"/> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x806" width="0.4"/> </header> <header name="ARP"> - <bits name="hrd" above="16" below="1" width=".3"/> - <bits name="pro" above="16" below="0x800" width=".3"/> - <bits name="hln" above="8" below="6" width=".2"/> - <bits name="pln" above="8" below="4" width=".2"/> - <bits name="op" above="16" width=".2" fill="yes"/> - <bits name="sha" above="48" width="0.5" fill="yes"/> - <bits name="spa" above="16" width="0.3" fill="yes"/> - <bits name="tha" above="48" width="0.5" fill="yes"/> - <bits name="tpa" above="16" width="0.3" fill="yes"/> + <bits name="hrd" above="16" below="1" width=".3"/> + <bits name="pro" above="16" below="0x800" width=".3"/> + <bits name="hln" above="8" below="6" width=".2"/> + <bits name="pln" above="8" below="4" width=".2"/> + <bits name="op" above="16" width=".2" fill="yes"/> + <bits name="sha" above="48" width="0.5" fill="yes"/> + <bits name="spa" above="16" width="0.3" fill="yes"/> + <bits name="tha" above="48" width="0.5" fill="yes"/> + <bits name="tpa" above="16" width="0.3" fill="yes"/> </header> </diagram> @@ -4362,22 +4362,22 @@ r r c c c. <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> </header> <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" below="6" width="0.3"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4"/> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" below="6" width="0.3"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4"/> </header> <header name="TCP"> - <bits name="src" above="16" width=".2"/> - <bits name="dst" above="16" width=".2"/> - <bits name="..." width=".75"/> - <bits name="flags" above="12" width=".3"/> - <bits name="..." width=".6"/> + <bits name="src" above="16" width=".2"/> + <bits name="dst" above="16" width=".2"/> + <bits name="..." width=".75"/> + <bits name="flags" above="12" width=".3"/> + <bits name="..." width=".6"/> </header> <dots/> </diagram> @@ -4413,30 +4413,30 @@ r r c c c. </p> <diagram> - <header> - <bits name="zero" above="4" below="0" width=".9"/> - </header> - <nospace/> - <header name="reserved"> - <bits name="[800]" above="1" width=".35"/> - <bits name="[400]" above="1" width=".35"/> - <bits name="[200]" above="1" width=".35"/> - </header> - <nospace/> - <header name="later RFCs"> - <bits name="NS" above="1" width=".35"/> - <bits name="CWR" above="1" width=".35"/> - <bits name="ECE" above="1" width=".35"/> - </header> - <nospace/> - <header name="RFC 793"> - <bits name="URG" above="1" width=".35"/> - <bits name="ACK" above="1" width=".35"/> - <bits name="PSH" above="1" width=".35"/> - <bits name="RST" above="1" width=".35"/> - <bits name="SYN" above="1" width=".35"/> - <bits name="FIN" above="1" width=".35"/> - </header> + <header> + <bits name="zero" above="4" below="0" width=".9"/> + </header> + <nospace/> + <header name="reserved"> + <bits name="[800]" above="1" width=".35"/> + <bits name="[400]" above="1" width=".35"/> + <bits name="[200]" above="1" width=".35"/> + </header> + <nospace/> + <header name="later RFCs"> + <bits name="NS" above="1" width=".35"/> + <bits name="CWR" above="1" width=".35"/> + <bits name="ECE" above="1" width=".35"/> + </header> + <nospace/> + <header name="RFC 793"> + <bits name="URG" above="1" width=".35"/> + <bits name="ACK" above="1" width=".35"/> + <bits name="PSH" above="1" width=".35"/> + <bits name="RST" above="1" width=".35"/> + <bits name="SYN" above="1" width=".35"/> + <bits name="FIN" above="1" width=".35"/> + </header> </diagram> </field> @@ -4450,20 +4450,20 @@ r r c c c. <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> </header> <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" below="17" width="0.3"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4"/> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" below="17" width="0.3"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4"/> </header> <header name="UDP"> - <bits name="src" above="16" width=".2"/> - <bits name="dst" above="16" width=".2"/> - <bits name="..." width=".4"/> + <bits name="src" above="16" width=".2"/> + <bits name="dst" above="16" width=".2"/> + <bits name="..." width=".4"/> </header> <dots/> </diagram> @@ -4480,20 +4480,20 @@ r r c c c. <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> </header> <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" below="132" width="0.3"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4"/> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" below="132" width="0.3"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4"/> </header> <header name="SCTP"> - <bits name="src" above="16" width=".2"/> - <bits name="dst" above="16" width=".2"/> - <bits name="..." width=".8"/> + <bits name="src" above="16" width=".2"/> + <bits name="dst" above="16" width=".2"/> + <bits name="..." width=".8"/> </header> <dots/> </diagram> @@ -4505,20 +4505,20 @@ r r c c c. <h2>ICMPv4</h2> <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x800" width="0.4"/> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x800" width="0.4"/> </header> <header name="IPv4"> - <bits name="..." width="0.4"/> - <bits name="proto" above="8" below="1" width="0.3"/> - <bits name="src" above="32" width="0.4"/> - <bits name="dst" above="32" width="0.4"/> + <bits name="..." width="0.4"/> + <bits name="proto" above="8" below="1" width="0.3"/> + <bits name="src" above="32" width="0.4"/> + <bits name="dst" above="32" width="0.4"/> </header> <header name="ICMPv4"> - <bits name="type" above="8" width=".3"/> - <bits name="code" above="8" width=".3"/> - <bits name="..." width=".8"/> + <bits name="type" above="8" width=".3"/> + <bits name="code" above="8" width=".3"/> + <bits name="..." width=".8"/> </header> <dots/> </diagram> @@ -4538,20 +4538,20 @@ r r c c c. <h2>ICMPv6</h2> <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x86dd" width="0.4"/> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x86dd" width="0.4"/> </header> <header name="IPv6"> - <bits name="..." width="0.2"/> - <bits name="next" above="8" below="58" width="0.3"/> - <bits name="src" above="128" width="0.4"/> - <bits name="dst" above="128" width="0.4"/> + <bits name="..." width="0.2"/> + <bits name="next" above="8" below="58" width="0.3"/> + <bits name="src" above="128" width="0.4"/> + <bits name="dst" above="128" width="0.4"/> </header> <header name="ICMPv6"> - <bits name="type" above="8" width=".3"/> - <bits name="code" above="8" width=".3"/> - <bits name="..." width=".8"/> + <bits name="type" above="8" width=".3"/> + <bits name="code" above="8" width=".3"/> + <bits name="..." width=".8"/> </header> <dots/> </diagram> @@ -4561,31 +4561,31 @@ r r c c c. <h2>ICMPv6 Neighbor Discovery</h2> <diagram> <header name="Ethernet"> - <bits name="dst" above="48" width="0.4"/> - <bits name="src" above="48" width="0.4"/> - <bits name="type" above="16" below="0x86dd" width="0.4"/> + <bits name="dst" above="48" width="0.4"/> + <bits name="src" above="48" width="0.4"/> + <bits name="type" above="16" below="0x86dd" width="0.4"/> </header> <header name="IPv6"> - <bits name="..." width="0.2"/> - <bits name="next" above="8" below="58" width="0.3"/> - <bits name="src" above="128" width="0.4"/> - <bits name="dst" above="128" width="0.4"/> + <bits name="..." width="0.2"/> + <bits name="next" above="8" below="58" width="0.3"/> + <bits name="src" above="128" width="0.4"/> + <bits name="dst" above="128" width="0.4"/> </header> <header name="ICMPv6"> - <bits name="type" above="8" below="135/136" width=".3"/> - <bits name="code" above="8" below="0" width=".3"/> - <bits name="..." width=".8"/> + <bits name="type" above="8" below="135/136" width=".3"/> + <bits name="code" above="8" below="0" width=".3"/> + <bits name="..." width=".8"/> </header> <header name="ICMPv6 ND"> - <bits name="target" above="128" width=".4"/> - <bits name="option ..." width=".6"/> + <bits name="target" above="128" width=".4"/> + <bits name="option ..." width=".6"/> </header> </diagram> <field id="MFF_ND_TARGET" title="ICMPv6 Neighbor Discovery Target IPv6"/> <field id="MFF_ND_SLL" - title="ICMPv6 Neighbor Discovery Source Ethernet Address"/> + title="ICMPv6 Neighbor Discovery Source Ethernet Address"/> <field id="MFF_ND_TLL" - title="ICMPv6 Neighbor Discovery Target Ethernet Address"/> + title="ICMPv6 Neighbor Discovery Target Ethernet Address"/> </group> <h1>References</h1> diff --git a/lib/ofp-print.c b/lib/ofp-print.c index 68e382471..05a39c22b 100644 --- a/lib/ofp-print.c +++ b/lib/ofp-print.c @@ -1634,12 +1634,12 @@ print_tlv_table(struct ds *s, struct ovs_list *mappings) struct ofputil_tlv_map *map; ds_put_cstr(s, " mapping table:\n"); - ds_put_cstr(s, " class\ttype\tlength\tmatch field\n"); - ds_put_cstr(s, " -----\t----\t------\t-----------"); + ds_put_cstr(s, " class type length match field\n"); + ds_put_cstr(s, " ------ ---- ------ --------------"); LIST_FOR_EACH (map, list_node, mappings) { - ds_put_char(s, '\n'); - ds_put_format(s, " 0x%"PRIx16"\t0x%"PRIx8"\t%"PRIu8"\ttun_metadata%"PRIu16, + ds_put_format(s, "\n %#6"PRIx16" %#4"PRIx8" %6"PRIu8" " + "tun_metadata%"PRIu16, map->option_class, map->option_type, map->option_len, map->index); } |