SunnyQjm/openflow
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Spec: clarify execution order of actions

Browse Source
This commit is contained in:
Brandon Heller
2009-11-20 18:10:46 -08:00
committed by Glen Gibb
parent fde98c8df4
commit d7707dc0af
2 changed files with 9 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/of-spec/openflow-spec-v0.9.0.tex
+6 -1
View File
@@ -169,7 +169,9 @@ Table \ref{table:counters} contains the required set of counters. Duration refe
\subsection{Actions}
\label{ft:actions}
Each flow entry is associated with zero or more actions that dictate how the switch handles matching packets. Actions need not be executed in the order in which they are specified in the flow entry. If no actions are present, the packet is dropped.
Each flow entry is associated with zero or more actions that dictate how the switch handles matching packets. If no forward actions are present, the packet is dropped. Action lists for \emph{inserted} flow entries MUST be processed in the order specified. However, there is no packet output ordering guaranteed within a port. For example, an action list may result in two packets sent to two different VLANs on a single port. These two packets may be arbitrarily re-ordered, but the packet bodies must match those generated from a sequential execution of the actions.
\\\\
A switch may reject a flow entry if it cannot process the action list in the order specified, in which case it should immediately return an unsupported flow error (see \ref{unsupported_flow}). Ordering within a port may vary between vendor switch implementations.
\\\\
A switch is not required to support all action types --- just those marked ``Required Actions'' below. When connecting to the controller, a switch indicates which of the ``Optional Actions'' it supports. OpenFlow-compliant switches come in two types: \emph{OpenFlow-only}, and \emph{OpenFlow-enabled}.
\\\\
@@ -402,6 +404,9 @@ For non-strict MODIFY and DELETE commands that contain wildcards, a match will o
DELETE and DELETE\_STRICT commands can be optionally filtered by output port. If the \verb|out_port| field contains a value other than \verb|OFPP_NONE|, it introduces a constraint when matching. This constraint is that the rule must contain an output action directed at that port. This field is ignored by ADD, MODIFY, and MODIFY\_STRICT messages.
\\\\
Emergency flow mod messages must have timeout values set to zero. Otherwise, the switch must refuse the addition and respond with an \verb|ofp_error_msg| with \verb|OFPET_FLOW_MOD_FAILED| type and \verb|OFPFMFC_BAD_EMERG_TIMEOUT| code.
\\\\
\label{unsupported_flow}If a switch cannot process the action list for any flow mod message in the order specified, it MUST immediately return an \verb|OFPET_FLOW_MOD_FAILED| :
\verb|OFPFMFC_UNSUPPORTED| error and reject the flow.
\subsection{Flow Removal}
include/openflow/openflow.h
+3 -1
View File
@@ -659,7 +659,9 @@ enum ofp_flow_mod_failed_code {
OFPFMFC_EPERM, /* Permissions error. */
OFPFMFC_BAD_EMERG_TIMEOUT, /* Flow not added because of non-zero idle/hard
* timeout. */
OFPFMFC_BAD_COMMAND /* Unknown command. */
OFPFMFC_BAD_COMMAND, /* Unknown command. */
OFPFMFC_UNSUPPORTED /* Unsupported action list - cannot process in
* the order specified. */
};
/* ofp_error_msg 'code' values for OFPET_PORT_MOD_FAILED. 'data' contains