Allow only OpenFlow 12 as a flow dump protocol.
The implementation of set_protocol_for_flow_dump ensures that
this will only be selected if an OpenFlow12 connection has
been negotiated.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Versions may be configured using the protocols column of
the bridge table. The protocols column is a set which accepts zero
or more of the values: 'OpenFlow10' and 'OpenFlow12'.
If the protocols column is empty, then OpenFlow10 is used.
This default is consistent with the behaviour of ovs-vswtichd
prior to this patch.
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com adjusted comments and documentation]
Signed-off-by: Ben Pfaff <blp@nicira.com>
This was meant to splice OXM support into OpenFlow 1.0, in place of NXM,
but I no longer see any value in it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
Soon, it's not going to be possible to switch between every possible
protocol on an established OpenFlow connection, yet
ofputil_encode_set_protocol() didn't have a documented way to report such
a problem. This commit adds a means for reporting and makes its callers
able to handle the problem.
Also, initially make ofputil_encode_set_protocol() fail when the current
and requested protocols are for different OpenFlow versions.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
It wasn't clear to me, at least, whether an OFPUTIL_P_* constant
indicated an OpenFlow version and a flow format or just a flow format.
After some reflection, I think it's more useful if it indicates both,
because otherwise it might be necessary to pass both an OpenFlow version
and an OFPUTIL_P_* constant in some contexts, but this way only the latter
is needed.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
This doesn't fix a visible bug, because code to send OpenFlow messages
updates the length itself, but it still seems like the right thing to do.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This code has, until now, parsed and accepted invalid bitmaps. It seems
better to simply ignore them, leaving the original set of allowed versions
from the version field in the ofp_header.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The length of the hello version bitmap is measured in bytes
so the return value of sizeof is sufficient. Dividing
this by CHAR_BIT (=8) seems to be an artifact of reworking
a previous version of this code.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Allow encoding and decoding of version bitmap in hello messages
as specified in Open Flow 1.3.1.
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com simplified and generalized decode/encode functions]
Signed-off-by: Ben Pfaff <blp@nicira.com>
The bitmap is simple a uint32_t, allowing for versions up until
wire-protocol number 31.
Bit offsets correspond to ofp_version numbers which in turn
correspond to wire-protocol numbers for Open Flow versions..
E.g. (1 << OFP10_VERSION) is the mask for Open Flow 1.1.
If the bit for a version is set then it is allowed, otherwise it is
disallowed.
This is in preparation for allowing the range of allowed OpenFlow
versions to be configured.
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com simplified some functions to constants, and rewrote
a few functions in terms of utility bitwise functions]
Signed-off-by: Ben Pfaff <blp@nicira.com>
When a link is down, or when a link has no speed because it is not a
physical interface, Open vSwitch previously reported that its rate is 100
Mbps as a default. This is counterintuitive, however, so this commit
changes Open vSwitch behavior to report 0 Mbps when a link is down or its
speed is otherwise unavailable.
Bug #13388.
Reported-by: Hiroshi Tanaka <htanaka@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
With this commit, OVS will match the data in the RARP packets having
ethertype 0x8035, in the same way as the data in the ARP packets.
Signed-off-by: Mehak Mahajan <mmahajan@nicira.com>
Commit c6100d92142b (ovs-ofctl: Accept port keywords, OF1.1 port numbers,
reject port number 0.) intentionally prohibited using port 0, which is not
a valid OpenFlow port number, in OpenFlow commands and actions. However,
since then we have discovered that the NVP controller uses port 0 in
"resubmit" actions and hence in flow matches as well. This seems like a
valid enough use case; after all, the port number in a resubmit action is
really just an arbitrary number that need not (and preferably does not)
refer to an actual OpenFlow port. Therefore, this commit restores the
ability to use port 0.
(Only functions that parse OpenFlow commands and actions from strings, not
those that interpret binary OpenFlow coming in on OpenFlow connections,
were affected by this prohibition, so this only comes up in corner cases
anyhow.)
Reported-by: Gurucharan Shetty <gshetty@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
When I wrote this function I didn't think that port 0 was important (it's
not a valid OpenFlow port number) so I used a return value of 0 to indicate
an error. However, my assumption turns out to be wrong, so this commit
changes the interface to use the return value only for error reporting
and store the parsed port number into a pointer passed in as a parameter.
This commit doesn't change the behavior of ofputil_port_from_string().
Signed-off-by: Ben Pfaff <blp@nicira.com>
When the command of a Flow Mod messages is ADD the cookie should be set as
fm->new_cookie, this is the new cookie value to be set. Otherwise it
should be set as fm->cookie, internally this is the cookie value to match.
Also remove 'XXX' marker from the matching code in the decoder.
I am now comfortable with the implementation.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This allows for encoding and decoding Open Flow 1.1 and 1.2 Queue Stats
Request and Reply messages.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This function changed a few times before it was merged,
unfortunately at some point the comment wasn't kept in sync
with the changes.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The return type of both ofputil_decode_flow_removed() and nx_pull_match()
is enum ofperr so it makes sense for error be of that type too.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This allows for encoding and decoding Open Flow 1.1 and 1.2 Port Stats
Request and Reply message
Signed-off-by: Simon Horman <horms@verge.net.au>
[blp@nicira.com added ofputil_count_port_stas(), simplified
interface of ofputil_decode_port_stats(), style changes]
Signed-off-by: Ben Pfaff <blp@nicira.com>
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>
