OpenFlow 1.0 through 1.3 have a message OFPT_QUEUE_GET_CONFIG_REQUEST and
its corresponding reply, for fetching a description of the queues
configured on a given port. OpenFlow 1.4 changes this message to a
multipart message OFPMP_QUEUE_DESC, which Open vSwitch has not until now
implemented. This commit adds an implemntation of that message. Because
the message is a replacement for the former one, this commit implements it
using the same ofp-util functions as the former message, so that the client
code doesn't have to distinguish a difference between versions.
The ovs-ofctl command queue-get-config was previously undocumented (due
only to an oversight). This commit corrects that and documents the new
feature available with OpenFlow 1.4.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
These are all just copies of the otherwise generic ofp_prop_header or
ofp_prop_experimenter.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Several OpenFlow 1.3+ messages use TLV-based properties that take a
common form. Until now, ofp-util has had some static functions for
dealing with properties. Because properties will start to be needed
outside of ofp-util, this commit breaks them out into a new library,
renaming them to begin with ofpprop_.
The following commit will add a few new interfaces that add new
functionality.
Signed-off-by: Ben Pfaff <blp@ovn.org>
At first glance, OF1.4 queue properties look a lot like those for OF1.0
to OF1.3, but in fact their different padding makes them incompatible. In
addition, OF1.4 switches from using regular OpenFlow messages to request
queue properties, to using multipart messages. Thus, we really need to
use separate code to deal with OF1.4 queues.
OF1.0, OF1.1, and OF1.2 all have slightly different queue config reply
messages, but only OF1.0 and OF1.2 had tests, so this adds tests. (There
is no test for OF1.3 because it's the same as OF1.2.)
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Experimenter stats are handled by code in ofp-msgs, and this struct isn't
good for anything.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
The structures declared in ofp-msgs.h for messages definitions should not
include an OpenFlow header (its presence is implied), but the definition of
these messages did. This commit fixes the definitions.
The visible bug was really minor here: messages of these kinds without any
TLVs would be rejected by the OpenFlow parser. But OVS never sends these
messages without TLVs, so probably no one ever noticed this. (Also, the
OVS support for OF1.4 is still incomplete and experimental.)
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
This patch renames the command name related with geneve-map to a more
generic name as following:
add-geneve-map -> add-tlv-map
del-geneve-map -> del-tlv-map
dump-geneve-map -> dump-tlv-map
It also renames the Geneve_table to tlv_table.
By doing this renaming, the NSH variable context header (the same TLV
format as Geneve) or other protocol can reuse the field tun_metadata<N>
in the future.
Signed-off-by: Mengke Liu <mengke.liu@intel.com>
Signed-off-by: Ricky Li <ricky.li@intel.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
This patch adds support for Openflow1.4 error codes for set-async-config.
In this patch, a new error type, OFPET_ASYNC_CONFIG_FAILED is introduced
that enables the switch to properly inform the controller when controller
tries to set invalid mask or unsupported configuration.
Signed-off-by: Ambika Arora <ambika.arora@tcs.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Protocol-independent symbols OFPG_* were already defined in
openflow-common.h, so remove the protocol version dependent symbols.
Found by inspection.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Due to an error on my part the Netronome vendor Id is incorrect:
the last digit should be 'd' rather than '0' as per the
Netronome IEEE OUI.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This patch adds support for Openflow1.4 Group & meter change notification
messages. In a multi controller environment, when a controller modifies the
state of group and meter table, the request that successfully modifies this
state is forwarded to other controllers. Other controllers are informed with
the OFPT_REQUESTFORWARD message. Request forwarding is enabled on a per
controller channel basis using the Set Asynchronous Configuration Message.
Signed-off-by: Niti Rohilla <niti.rohilla@tcs.com>
Co-authored-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Define struct eth_addr and use it instead of a uint8_t array for all
ethernet addresses in OVS userspace. The struct is always the right
size, and it can be assigned without an explicit memcpy, which makes
code more readable.
"struct eth_addr" is a good type name for this as many utility
functions are already named accordingly.
struct eth_addr can be accessed as bytes as well as ovs_be16's, which
makes the struct 16-bit aligned. All use seems to be 16-bit aligned,
so some algorithms on the ethernet addresses can be made a bit more
efficient making use of this fact.
As the struct fits into a register (in 64-bit systems) we pass it by
value when possible.
This patch also changes the few uses of Linux specific ETH_ALEN to
OVS's own ETH_ADDR_LEN, and removes the OFP_ETH_ALEN, as it is no
longer needed.
This work stemmed from a desire to make all struct flow members
assignable for unrelated exploration purposes. However, I think this
might be a nice code readability improvement by itself.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
It's possible to imagine that a switch might want to report additional
capabilities related to Geneve beyond just the number of options and
how much space they can consume. Some examples include additional
restrictions on parsing (if this command is used for non-OVS implementations
or OVS changes how it works) and per-packet actions that can't be done
generically (such as checksums or encryption). It's not yet clear if
these will be necessary or if OpenFlow is the right place to expose
them. However, it's easy to do now and there is very little cost so
it seems like a good idea to leave some additional reserved space.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This patch adds support for Openflow1.4 set/get asynchronous configuration
messages. OpenVSwitch already supports set/get asynchronous configuration
messages for Openflow1.3. In this patch OFPT_SET_ASYNC_CONFIG message
allows the controllers to set the configuration for OFPT_ROLE_STATUS,
OFPT_TABLE_STATUS and OFPT_REQUESTFORWARD in addition to the Openflow1.3
messages. In a OFPT_SET_ASYNC, only the properties that shall be changed
need to be included, properties that are omitted from the message are
unchanged.
The OFPT_GET_ASYNC_CONFIG is used to query the asynchronous configuration
of switch. In a OFPT_GET_ASYNC_REPLY message, all properties must be
included.
According to Openflow1.4 the initial configuration shall be:
- In the “master” or “equal” role, enable all OFPT_PACKET_IN messages,
except those with reason OFPR_INVALID_TTL, enable all OFPT_PORT_STATUS
and OFPT_FLOW_REMOVED messages, and disable all OFPT_ROLE_STATUS,
OFPT_TABLE_STATUS and OFPT_REQUESTFORWARD messages.
- In the “slave” role, enable all OFPT_PORT_STATUS messages and disable
all OFPT_PACKET_IN, OFPT_FLOW_REMOVED, OFPT_ROLE_STATUS,
OFPT_TABLE_STATUS and OFPT_REQUESTFORWARD messages.
Signed-off-by: Niti Rohilla <niti.rohilla@tcs.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Several encapsulation formats have the concept of an 'OAM' bit
which typically is used with networking tracing tools to
distinguish test packets from real traffic. OVS already internally
has support for this, however, it doesn't do anything with it
and it also isn't exposed for controllers to use. This enables
support through OpenFlow.
There are several other tunnel flags which are consumed internally
by OVS. It's not clear that it makes sense to use them externally
so this does not expose those flags - although it should be easy
to do so if necessary in the future.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
OpenFlow 1.4 introduces the ability to turn on flow table eviction with an
OFPT_TABLE_MOD message specifying OFPTC_EVICTION. It also adds related
machinery to other messages that mention OFPTC_* fields. This commit adds
support for the new feature, implementing it as a second, parallel way to
enable flow table eviction. It takes more work than it seems like it
should because there is so much weirdness with the treatment of OFPTC_*
flags over the evolution of OpenFlow; please refer to the explanation in
DESIGN.md for more information.
This commit also adds related support to ovs-ofctl, plus tests.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Co-authored-by: Saloni Jain <saloni.jain@tcs.com>
Signed-off-by: Saloni Jain <saloni.jain@tcs.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
In order to work with Geneve options, we need to maintain a mapping
table between an option (defined by <class, type, length>) and
an NXM field that can be operated on for the purposes of matches,
actions, etc. This mapping must be explicitly specified by the
user.
Conceptually, this table could be communicated using either OpenFlow
or OVSDB. Using OVSDB requires less code and definition of extensions
than OpenFlow but introduces the possibility that mapping table
updates and flow modifications are desynchronized from each other.
This is dangerous because the mapping table signifcantly impacts the
way that flows using Geneve options are installed and processed by
OVS. Therefore, the mapping table is maintained using OpenFlow commands
instead, which opens the possibility of using synchronization between
table changes and flow modifications through barriers, bundles, etc.
There are two primary groups of OpenFlow messages that are introduced
as Nicira extensions: modification commands (add, delete, clear mappings)
and table status request/reply to dump the current table along with switch
information.
Note that mappings should not be changed while they are in active use by
a flow. The result of doing so is undefined.
This only adds the OpenFlow infrastructure but doesn't actually
do anything with the information yet after the messages have been
decoded.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The final flow stats are available only after there are no references
to the rule. Postpone sending the flow removed message until the
final stats are available.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This means that anyone who adds another openflow include file automatically
gets it checked. It does mean that changing any of the OpenFlow headers
causes all of them to be checked, but that doesn't seem like a big deal
(it's quick).
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@noironetworks.com>
As pointed out by Ben Pfaff NTR (NetronoMe eXtension) is confusingly
similar to NXM (Nicira eXtended Match?) which is already used widely
in the Open vSwitch tree.
To get ease future eye strain use NTR (NeTRonome) instead of NTR,
starting with the only instance currently present in the tree,
the Netronome vendor id.
This is in preparation for actually using the Netronome vendor id.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The spec has been clarified to use _list_len in palce of _list_len
terminology to make it clearer that the data is not an ordered list
(it is a set). The code present in Open vSwitch already avoided
the _list_len terminology. This change brings the code into
line with the updated spec.
ONF-JIRA: EXT-350
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The spec has been clarified to note that element 4 of
enum ofp_group_mod_command is reserved. This patch reflects
that change.
ONF-JIRA: EXT-350
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This patch enables a user to set importance for a new rule via add-flow
OF1.4+ in the OVS and display the same via dump-flows command OF1.4+.
The changes are made in accordance with OpenFlow 1.4 specs to implement
eviction on the basis of "importance". This patch also enhances the
diff-flows & replace-flows CLI for addition of importance parameter in
a rule.
This doesn't actually implement eviction on the basis of importance, which
will happen in a later patch.
Signed-off-by: Rishi Bamba <rishi.bamba@tcs.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
This field allows a flow table to match on the output port currently in the
action set.
ONF-JIRA: EXT-233
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
This improves the general abstraction of OXM/NXM by eliminating direct
knowledge of it from the meta-flow code and other places.
Some function renaming might be called for; for example, mf_oxm_header()
may not be the best name now that the function is implemented within
nx-match. However, these renamings would make this commit larger and
harder to review, so I'm postponing them.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
This is a first step toward improving the abstraction of OXM and NXM in the
tree. As an immediate improvement, this commit removes all of the
definitions of the OXM and NXM constants from the top-level header files,
because they are no longer used anywhere.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
The Open vSwitch "make" output was still pretty verbose even when
configured with --enable-silent-rules. This cleans it up.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Joe Stringer <joestringer@nicira.com>
These error codes are proposed in the ONF extensibility working group as an
OpenFlow 1.3 extension.
Error codes are also proposed for the other three "bad property" error
codes, but those already have standardized OpenFlow 1.3 error codes and the
proposal says that implementations should use the standard ones.
ONF-JIRA: EXT-444.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now, knowledge about OpenFlow has been somewhat scattered around the
tree. Some of it is in ofp-actions, some of it is in ofp-util, some in
separate files for individual actions, and most of the wire format
declarations are in include/openflow. This commit centralizes all of that
in ofp-actions.
Encoding and decoding OpenFlow actions was previously broken up by OpenFlow
version. This was OK with only OpenFlow 1.0 and 1.1, but each additional
version added a new wrapper around the existing ones, which started to
become hard to understand. This commit merges all of the processing for
the different versions, to the extent that they are similar, making the
version differences clearer.
Previously, ofp-actions contained OpenFlow encoding and decoding, plus
ofpact formatting, but OpenFlow parsing was separated into ofp-parse, which
seems an odd division. This commit moves the parsing code into ofp-actions
with the rest of the code.
Before this commit, the four main bits of code associated with a particular
ofpact--OpenFlow encoding and decoding, ofpact formatting and parsing--were
all found far away from each other. This often made it hard to see what
was going on for a particular ofpact, since you had to search around to
many different pieces of code. This commit reorganizes so that all of the
code for a given ofpact is in a single place.
As a code refactoring, this commit has little visible behavioral change.
The update to ofproto-dpif.at illustrates one minor bug fix as a side
effect: a flow that was added with the action "dec_ttl" (a standard
OpenFlow action) was previously formatted as "dec_ttl(0)" (using a Nicira
extension to specifically direct packets bounced to the controller because
of too-low TTL), but after this commit it is correctly formatted as
"dec_ttl".
The other visible effect is to drop support for the Nicira extension
dec_ttl action in OpenFlow 1.1 and later in favor of the equivalent
standard action. It seems unlikely that anyone was really using the
Nicira extension in OF1.1 or later.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
This will allow, later, to centralize all of the knowledge of instruction
encoding inside ofp-actions.
OFPIT11_ALL and OFPIT13_ALL are no longer used, so this commit removes
them. Their definitions were wrong (they did not shift each bit into
position correctly), so this commit is also a small bug fix.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
Until now, sets of actions have been abstracted separately outside
ofp-actions, as enum ofputil_action_bitmap. Drawing sets of actions into
ofp-actions, as done in this commit, makes for a better overall
abstraction of actions, with better consistency.
A big part of this commit is shifting from using ofp12_table_stats as if
it were an abstraction for OpenFlow table stats, toward using a new
struct ofputil_table_stats, which is what we generally do with other
OpenFlow structures and fits better with the rest of the code.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
These 64-bit registers are intended to conform with the OpenFlow 1.5
draft specification.
EXT-244.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
This is in preparation for supporting OpenFlow1.4
flow monitor requests.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
When a flow with a "learn" action is deleted, one often wants the flows
that it created (the "learned flows") to be deleted as well. This commit
makes that possible.
I am aware of a race condition that could lead to a learned flow not being
properly deleted. Suppose thread A deletes a flow with a "learn" action.
Meanwhile, thread B obtains the actions for this flow and translates and
executes them. Thread B could obtain the actions for the flow before it is
deleted, but execute them after the "learn" flow and its learned flows are
deleted. The result is that the flow created by thread B persists despite
its "learn" flow having been deleted. This race can and should be fixed,
but I think that this commit is worth reviewing without it.
VMware-BZ: #1254021
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Ethan Jackson <ethan@nicira.com>
