Soon the kernel will begin supplying the information about the outer
IP header for tunneled packets and userspace will need to be able to
track it as part of the flow. For the time being this is only used
internally by OVS and not exposed outwards to OpenFlow. As a result,
this threads the information throughout userspace but simply stores
the existing tun_id in it.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Previously this field was ignored on decode and
set to zero on encode
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com changed "missing" value, removed OFPTT_ALL]
Signed-off-by: Ben Pfaff <blp@nicira.com>
This is a necessary step toward supporting full 32-bit OF1.1+ port numbers
in a later version of OVS.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
Previously there was no need for this, because all implemented standard
OpenFlow actions had a fixed length, but the OF1.2 "set-field" action (soon
to be implemented) is variable length.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
The numbering of OpenFlow 1.0 actions overlaps with the numbering
of OpenFlow 1.1+ actions, so the two sets of actions have to be
distinguished for input and output. But OpenFlow 1.1 and 1.2
actions are numbered to avoid this problem, so there is no need
to distinguish them in the same way. Therefore, this commit
prepares to treat them together.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
OpenFlow 1.0 has special reserved ports in the range 0xfff8 to 0xffff.
OpenFlow 1.1 and later has the same ports in the range 0xfffffff8 to
0xffffffff and allows the OF1.0 range to be used for ordinary ("physical")
switch ports. This means that, naively, the meaning of a port number in
the range 0xfff8 to 0xffff given on the ovs-ofctl command line depends on
the protocol in use. This commit implements something a little smarter:
- Accept keyword names (e.g. LOCAL) for special reserved ports
everywhere that such a port can plausibly be used (previously they
were only accepted in some places).
- Translate 0xfff8...0xffff to 0xfffffff8...0xffffffff for now, since
OF1.1+ isn't in widespread use and those particular ports aren't
likely to be in use in OF1.1+ anyway.
- Log warnings about those ports when they are specified by number, to
allow users to fix their invocations.
Also:
- Accept the OF1.1+ port numbers for these ports, without warning, for
compatibility with the upcoming OF1.1+ support.
- Stop accepting port number 0, which has never been a valid port
number in OpenFlow 1.0 and later. (This required fixing some tests
that inadvertently used this port number).
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com then made substantial changes that were then:]
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
* In the case of OpenFlow 1.2+ OFPERR_OFPBRC_BAD_PORT is defined
in the specification and seems to be the most appropriate error
to use when an invalid port is encountered in a Packet Out request.
* In the case of OpenFlow 1.0 and 1.1 no appropriate error message
seems to exist. Perhaps because an invalid port is not possible?
I'm unsure.
In any case, make use of a non-standard error code (1,514).
This was formerly known as OFPERR_NXBRC_BAD_IN_PORT but
has been rolled into OFPERR_NXBRC_BAD_IN_PORT to allow the
latter to be used without concern for the prevailing Open Flow version.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add necessary macros to ofp-util for OF12 support.
This is just a placeholder.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
OFPERR_NXFMFC_GROUPS_NOT_SUPPORTED is currently only used in paths which
are part of a non-NX extension portions of the Open Flow 1.1+
implementation.
After recent discussion it has been decided to attempt to only use
standardised, albeit lest-specify, errors unless errors arise from use of
an NX extension.
With the above in mind it seems appropriate to:
* Use OFPERR_OFPFMFC_UNKNOWN in place of OFPERR_NXFMFC_GROUPS_NOT_SUPPORTED.
* Remove OFPERR_NXFMFC_GROUPS_NOT_SUPPORTED as it is no longer used.
An unfortunate side-effect of this change is that the error for
the case in question is now less-specific.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
It might have been a useful optimization at one point to have FWW_*
correspond in OFPFW10_* where possible, but it doesn't seem worthwhile for
only 3 corresponding values. It also makes the code somewhat more
confusing.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Split OFPRAW_OFPST_AGGREGATE_REQUEST into OpenFlow 1.0 and 1.1+
versions.
This should be sufficient to allow adding encoding and decoding of
Open Flow 1.1 and 1.2 Aggregate Stats Request messages.
Encoding and decoding of Open Flow 1.1 and 1.2 Aggregate Stats Response
messages works using the existing code without modification.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Allow decoding of Open Flow 1.1 and 1.2 flow statistics request messages.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
NXM and OpenFlow 1.2+ allow including the values of arbitrary flow metadata
in "packet-in" messages. Open vSwitch has until now always included all
the values of the metadata fields that it implements in NXT_PACKET_IN
messages.
However, this has at least two disadvantages:
- Most of the metadata fields tend to be zero most of the time, which
wastes space in the message.
- It means that controllers must be very liberal about accepting
fields that they know nothing about in packet-in messages, since any
switch upgrade could cause new fields to appear even if the
controller does nothing to give them nonzero values. (Controllers
have to be prepared to tolerate unknown fields in any case, but this
property makes unknown fields more likely to appear than otherwise.)
This commit changes Open vSwitch so that metadata fields whose values are
zero are not reported in packet-ins, fixing both problems. (This is
explicitly allowed by OpenFlow 1.2+.)
This commit mainly fixes a sort of internal conceptual dissonance centering
around struct flow_metadata. This structure is supposed to report the
metadata for a given flow. If you look at a flow, it has particular
metadata values; it doesn't have masks, and the idea of a mask for a
particular flow doesn't really make sense. However, struct flow_metadata
did have masks. This led to internal confusion; one can see this in, for
example, the following code removed by this commit in ofproto-dpif.c to
handle misses in the OpenFlow flow table:
/* Registers aren't meaningful on a miss. */
memset(pin.fmd.reg_masks, 0, sizeof pin.fmd.reg_masks);
What this code was really trying to say is that on a flow miss, the
registers are zero, so they shouldn't be included in the packet-in message.
It did manage to omit the registers, by marking them as "wild", but it is
conceptually more correct to simply omit them because they are zero (and
that's one effect of this commit).
Bug #12968.
Reported-by: Igor Ganichev <iganichev@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Split OFPRAW_OFPST_FLOW_{REQUEST,REPLY} into OpenFlow 1.0 and 1.1+
versions.
This is in preparation for adding encoding and decoding of
Open Flow 1.1 & 1.2 messages.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
When encoding Open Flow 1.1 & 1.2 Port Mod Request messages
the port number should be converted to 32bits using
ofputil_port_to_ofp11() rather than htonl(). This ensures
that port numbers in the reserved range are translated correctly.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com added support for hard_timeout, plus a test]
Signed-off-by: Ben Pfaff <blp@nicira.com>
ofputil_decode_flow_removed() doesn't yet support OF1.2 at all so that
piece is missing but this otherwise should be complete.
CC: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
* Allow OXM matches which specified in OpenFlow 1.2.
Also allow them for OpenFlow 1.1 as there seems little reason not to.
* Pass padded_match_len parameter which if on NULL will be set to
the padded match len. This will be used when decoding flow statistics
response messages.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
OVS has all kinds of odd fields, e.g. registers, and it doesn't make sense
to try to match on all of them. This commit changes learning-switch to
only try to match on the fields defined by OpenFlow 1.0. That's still not
minimal, but it's more reasonable.
This commit should not have an immediately visible effect since
ovs-controller always sends OF1.0 format flows to the switch, and OF1.0
format flows don't have these extra fields. But in the future when we
add support for new protocols and flow formats to ovs-controller, it
will make a difference.
Signed-off-by: Ben Pfaff <blp@nicira.com>
In the case of Open Flow 1.2, which is currently the only
time that OXM is be used, there is a 4 byte header before
the match which needs to be taken into account when calculating
the pad length. This complicates nx_match pull and put somewhat.
This patch takes an approach suggested by Ben Pfaff to separate the
encoding of the match and the adding of padding and, in the case of OXM,
a header.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
As of Open Flow 1.1 what was the actions element of
struct switch_features becomes reserved. As such
it seems sensible to always decode it as zero.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This comment is talking about the obsolete "tun_id_from_cookie" protocol
extension that we removed from OVS long ago.
Signed-off-by: Ben Pfaff <blp@nicira.com>
There are capabilities which are present in one, two and three
of Open Flow 1.0, 1.1 and 1.2. Update OFPC_COMMON to only include
capabilities that are present in all three Open Flow versions and
add ofputil_capabilities_mask() to return the mask of capabilities
for each version.
This does not cover OFPUTIL_C_STP and OFPUTIL_C_GROUP_STATS, which
both use capability bit 3 and are treated as special cases in
ofputil_encode_switch_features() and ofputil_decode_switch_features().
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reduce scope of per-protocol variables in ofputil_encode_flow_mod()
These variables are only needed in one of the cases covered by the switch
statement and will increase in number as more cases (protocols) are
supported.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Add action bits for Open Flow 1.2, these are not the same as Open Flow 1.1.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
