SunnyQjm/openflow
1
0 Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
bd9dd435543fb1ea449385c4afb99704cbe63acc
openflow/doc/of-spec/appendix.tex
T
Glen Gibb bd9dd43554 spec: clarify actions field in ofp_switch_features 
Clarify that the actions field is used only for reporting back the
standard actions defined in the Actions section of the document, not for
vendor-specific actions.
2009-12-31 15:51:34 -08:00

430 lines
30 KiB
TeX
Executable File
Raw Blame History

%\appendix
\section{Appendix A: The OpenFlow Protocol}
The heart of the OpenFlow spec is the set of structures used for OpenFlow Protocol messages.
\\\\
The structures, defines, and enumerations described below are derived from the file \verb|include/openflow/openflow.h|, which is part of the standard OpenFlow distribution. All structures are packed with padding and 8-byte aligned, as checked by the assertion statements. All OpenFlow messages are sent in big-endian format.
\subsection{OpenFlow Header}
Each OpenFlow message begins with the OpenFlow header:
\input{struct/ofp_header}
The version specifies the OpenFlow protocol version being used. During the current draft phase of the OpenFlow Protocol, the most significant bit will be set to indicate an experimental version and the lower bits will indicate a revision number. The current version is \input{define/OFP_VERSION}. The final version for a Type 0 switch will be 0x00. The length field indicates the total length of the message, so no additional framing is used to distinguish one frame from the next. The type can have the following values:
\input{enum/ofp_type}
\subsection{Common Structures}
This section describes structures used by multiple messages.
\subsubsection{Port Structures}
Physical ports are described with the following structure:
\input{struct/ofp_phy_port}
The \verb|port_no| field is a value the datapath associates with a physical port. The \verb|hw_addr| field typically is the MAC address for the port; \verb|OFP_MAX_ETH_ALEN| is 6. The name field is a null-terminated string containing a human-readable name for the interface. The value of \verb|OFP_MAX_PORT_NAME_LEN| is 16.
\\\\
The \verb|config| field describes spanning tree and administrative settings with the following structure:
\input{enum/ofp_port_config}
The port config bits indicate whether a port has been administratively brought down, options for handling 802.1D spanning tree packets, and how to handle incoming and outgoing packets. These bits, configured over multiple switches, enable an OpenFlow network to safely flood packets along either a custom or 802.1D spanning tree.
\\\\
The controller may set \verb|OFPPFL_NO_STP| to 0 to enable STP on a port or to 1 to disable STP on a port. (The latter corresponds to the Disabled STP port state.) The default is switch implementation-defined; the OpenFlow reference implementation by default sets this bit to 0 (enabling STP).
\\\\
When \verb|OFPPFL_NO_STP| is 0, STP controls the \verb|OFPPFL_NO_FLOOD| and \verb|OFPPFL_STP_*| bits directly. \verb|OFPPFL_NO_FLOOD| is set to 0 when the STP port state is Forwarding, otherwise to 1. The bits in \verb|OFPPFL_STP_MASK| are set to one of the other \verb|OFPPFL_STP_*| values according to the current STP port state.
\\\\
When the port flags are changed by STP, the switch sends an \verb|OFPT_PORT_STATUS| message to notify the controller of the change. The \verb|OFPPFL_NO_RECV|, \verb|OFPPFL_NO_RECV_STP|, \verb|OFPPFL_NO_FWD|, and \verb|OFPPFL_NO_PACKET_IN| bits in the OpenFlow port flags may be useful for the controller to implement STP, although they interact poorly with in-band control.
\\\\
The \verb|state| field describes the spanning tree state and whether a physical link is present, with the following structure:
\input{enum/ofp_port_state}
All port state bits are read-only, representing spanning tree and physical link state.
\\\\
The port numbers use the following conventions:
\input{enum/ofp_port}
The \verb|curr|, \verb|advertised|, \verb|supported|, and \verb|peer| fields indicate link modes (10M to 10G full and half-duplex), link type (copper/fiber) and link features (autonegotiation and pause). Port features are represent by the following structure:
\input{enum/ofp_port_features}
Multiple of these flags may be set simultaneously.
\subsubsection{\qosupd{Queue Structures}}
\label{cts:qos}
\qosupd{An OpenFlow switch provides limited Quality-of-Service support
(QoS) through a simple queuing
mechanism. One (or more) queues can attach to a port and be used to map flows
on it. Flows mapped to a specific queue will be treated according to
that queue's configuration (e.g. min rate).
\\\\
A queue is described by the} \verb|ofp_packet_queue| \qosupd{structure:
\input{struct/ofp_packet_queue}
Each queue is further described by a set of properties, each of a
specific type and configuration.
\input{enum/ofp_queue_properties}
Each queue property description starts with a common header:
\input{struct/ofp_queue_prop_header}
Currently, there is only a minimum-rate type queue, described by the}
\verb|ofp_queue_prop_min_rate| \qosupd{structure:
\input{struct/ofp_queue_prop_min_rate}}
\subsubsection{Flow Match Structures}
When describing a flow entry, the following structure is used:
\input{struct/ofp_match}
The \verb|wildcards| field has a number of flags that may be set:
\input{enum/ofp_flow_wildcards}
If no wildcards are set, then the \verb|ofp_match| exactly describes a flow, over the entire OpenFlow 12-tuple. On the other extreme, if all the wildcard flags are set, then every flow will match.
\\\\
The source and destination netmasks are each specified with a 6-bit number in the wildcard description. It is interpreted similar to the CIDR suffix, but with the opposite meaning, since this is being used to indicate which bits in the IP address should be treated as ``wild". For example, a CIDR suffix of "24" means to use a netmask of ``255.255.255.0". However, a wildcard mask value of ``24" means that the least-significant 24-bits are wild, so it forms a netmask of ``255.0.0.0".
\subsubsection{Flow Action Structures}
A number of actions may be associated with flows or packets. The currently defined action types are:
\input{enum/ofp_action_type}
Output \qosupd{and enqueue} actions are described in Section \ref{ft:actions}, while Field-Modify actions are described in Table \ref{table:field modify actions}. An action definition contains the action type, length, and any associated data:
\input{struct/ofp_action_header}
An \verb|action_output| has the following fields:
\input{struct/ofp_action_output}
The \verb|max_len| indicates the maximum amount of data from a packet that should be sent when the port is \verb|OFPP_CONTROLLER|. If \verb|max_len| is zero, the switch must send a zero-size \verb|packet_in| message. The \verb|port| specifies the physical port from which packets should be sent.
\\\\
\qosupd{The enqueue action maps a flow to an already-configured queue, regardless of the TOS and VLAN PCP bits.
The packet should not change after an enqueue action. If the switch
needs to set the TOS/PCP bits for internal handling, the original values
should be restored before sending the packet out.
\\\\
A switch may support only queues that are tied to specific PCP/TOS
bits. In that case, we cannot map an arbitrary flow to a specific
queue, therefore the action ENQUEUE is not supported. The user can
still use these queues and map
flows to them by setting the relevant fields (TOS, VLAN PCP).
\\\\
The enqueue action has the following fields:
\input{struct/ofp_action_enqueue}}
An \verb|action_vlan_vid| has the following fields:
\input{struct/ofp_action_vlan_vid}
The \verb|vlan_vid| field is 16 bits long, when an actual VLAN id is only 12 bits. The value \verb|0xffff| is used to indicate that no VLAN id was set.
\\\\
An \verb|action_vlan_pcp| has the following fields:
\input{struct/ofp_action_vlan_pcp}
The \verb|vlan_pcp| field is 8 bits long, but only the lower 3 bits have meaning.
\\\\
An \verb|action_strip_vlan| takes no arguments and consists only of a generic \verb|ofp_action_header|. This action strips the VLAN tag if one is present.
\\\\
An \verb|action_dl_addr| has the following fields:
\input{struct/ofp_action_dl_addr}
The \verb|dl_addr| field is the MAC address to set.
\\\\
An \verb|action_nw_addr| has the following fields:
\input{struct/ofp_action_nw_addr}
The \verb|nw_addr| field is the IP address to set.
\\\\
An \verb|action_nw_tos| has the following fields:
\input{struct/ofp_action_nw_tos}
The \verb|nw_tos| field is the 6 upper bits of the ToS field to set, in the original bit positions (shifted to the left by 2).
\\\\
An \verb|action_tp_port| has the following fields:
\input{struct/ofp_action_tp_port}
The \verb|tp_port| field is the TCP/UDP/other port to set.
\\\\
An \verb|action_vendor| has the following fields:
\input{struct/ofp_action_vendor_header}
The \verb|vendor| field is the Vendor ID, which takes the same form as in struct \verb|ofp_vendor|.
\subsection{Controller-to-Switch Messages}
\subsubsection{Handshake}
\label{cts:handshake}
Upon TLS session establishment, the controller sends an \verb|OFPT_FEATURES_REQUEST| message. This message does not contain a body beyond the OpenFlow header. The switch responds with an \verb|OFPT_FEATURES_REPLY| message:
\input{struct/ofp_switch_features}
The \verb|datapath_id| field uniquely identifies a datapath. The lower 48 bits are intended for the switch MAC address, while the top 16 bits are up to the implementer. An example use of the top 16 bits would be a VLAN ID to distinguish multiple virtual switch instances on a single physical switch. This field should be treated as an opaque bit string by controllers.
\\\\
The \verb|n_tables| field describes the number of tables supported by the switch, each of which can have a different set of supported wildcard bits and number of entries. When the controller and switch first communicate, the controller will find out how many tables the switch supports from the Features Reply. If it wishes to understand the size, types, and order in which tables are consulted, the controller sends a \verb|OFPST_TABLE| stats request. A switch must return these tables in the order the packets traverse the tables, with all exact-match tables listed before all tables with wildcards.
\\\\
The \verb|capabilities| field uses the following flags:
\input{enum/ofp_capabilities}
The \verb|actions| field is a bitmap of actions supported by the switch. The list of actions is found in Section~\ref{ft:actions}; all actions marked Required must be supported. Vendor actions should \emph{not} be reported via this bitmask. The bitmask uses the values from \verb|ofp_action_type| as the number of bits to shift left for an associated action. For example, \verb|OFPAT_SET_DL_VLAN| would use the flag \verb|0x00000002|.
\\\\
The \verb|ports| field is an array of \verb|ofp_phy_port| structures that describe all the physical ports in the system that support OpenFlow. The number of port elements is inferred from the length field in the OpenFlow header.
\subsubsection{Switch Configuration}
The controller is able to set and query configuration parameters in the switch with the \verb|OFPT_SET_CONFIG| and \verb|OFPT_GET_CONFIG_REQUEST| messages, respectively. The switch responds to a configuration request with an \verb|OFPT_GET_CONFIG_REPLY| message; it does not reply to a request to set the configuration.
\\\\
There is no body for \verb|OFPT_GET_CONFIG_REQUEST| beyond the OpenFlow header. The \verb|OFPT_SET_CONFIG| and \verb|OFPT_GET_CONFIG_REPLY| use the following:
\input{struct/ofp_switch_config}
The configuration flags include the following:
\input{enum/ofp_config_flags}
The \verb|OFPC_FRAG_*| flags indicate whether IP fragments should be treated normally, dropped, or reassembled. ``Normal" handling of fragments means that an attempt should be made to pass the fragments through the OpenFlow tables. If any field is not present (e.g., the TCP/UDP ports didn't fit), then the packet should not match any entry that has that field set.
\\\\
The \verb|miss_send_len| field defines the number of bytes of each packet sent to the controller as a result of both flow table misses and flow table hits with the controller as the destination. If this field equals 0, the switch must send a zero-size \verb|packet_in| message.
\subsubsection{Modify State Messages}
\paragraph{Modify Flow Entry Message}
Modifications to the flow table from the controller are done with the \verb|OFPT_FLOW_MOD| message:
\input{struct/ofp_flow_mod}
The \verb|cookie| field is an opaque data value that is set by the
controller. It is not used in any matching functions, and thus does not
need to reside in hardware. The value -1 (0xffffffffffffffff) is
reserved and must not be used. It is required that when \verb|command| is
\verb|OFPC_MODIFY| or \verb|OFPC_MODIFY_STRICT| that matched flows have
their \verb|cookie| field updated appropriately.
\\\\
The \verb|command| field must be one of the following:
\input{enum/ofp_flow_mod_command}
The differences between \verb|OFPFC_MODIFY| and \verb|OFPFC_MODIFY_STRICT| are explained in Section \ref{flow_table:sec_chan:flow_mod} and differences between \verb|OFPFC_DELETE| and \verb|OFPFC_DELETE_STRICT| are explained in Section \ref{flow_table:sec_chan:flow_removal}.
\\\\
The \verb|idle_timeout| and \verb|hard_timeout| fields control how quickly flows expire.
\\\\
If the \verb|idle_timeout| is set and the \verb|hard_timeout| is zero, the entry must expire after \verb|idle_timeout| seconds with no received traffic. If the \verb|idle_timeout| is zero and the \verb|hard_timeout| is set, the entry must expire in \verb|hard_timeout| seconds regardless of whether or not packets are hitting the entry.
\\\\
If both \verb|idle_timeout| and \verb|hard_timeout| are set, the flow will timeout after \verb|idle_timeout| seconds with no traffic, or \verb|hard_timeout| seconds, whichever comes first. If both \verb|idle_timeout| and \verb|hard_timeout| are zero, the entry is considered permanent and will never time out. It can still be removed with a \verb|flow_mod| message of type \verb|OFPFC_DELETE|.
\\\\
The \verb|priority| field is only relevant for flow entries with wildcard fields. The priority field indicates table priority, where higher numbers are higher priorities; the switch must keep the highest-priority wildcard entries in the lowest-numbered (fastest) wildcard table, to ensure correctness. It is the responsibility of each switch implementer to ensure that exact entries always match before wildcards entries, regardless of the table configuration.
\\\\
The \verb|buffer_id| refers to a buffered packet sent by the \verb|OFPT_PACKET_IN| message.
\\\\
The \verb|out_port| field optionally filters the scope of DELETE and DELETE\_STRICT messages by output port. If \verb|out_port| 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. Other constraints such as \verb|ofp_match| structs and priorities are still used; this is purely an \emph{additional} constraint. Note that to disable output port filtering, \verb|out_port| must be set to \verb|OFPP_NONE|, since 0 is a valid port id. This field is ignored by ADD, MODIFY, and MODIFY\_STRICT messages.
\\\\
The \verb|flags| field may include the follow flags:
\input{enum/ofp_flow_mod_flags}
When the \verb|OFPFF_SEND_FLOW_REM| flag is set, the switch must send a flow removed message when the flow expires. The default is for the switch to not send flow removed messages for newly added flows.
\\\\
When the \verb|OFPFF_CHECK_OVERLAP| flag is set, the switch must check that there are no conflicting entries with the same priority. If there is one, the flow mod fails and an error code is returned.
\\\\
When the \verb|OFPFF_EMERG_| flag is set, the switch must consider this flow entry as an emergency entry, and only use it for forwarding when disconnected from the controller.
\paragraph{Port Modification Message}
The controller uses the \verb|OFPT_PORT_MOD| message to modify the behavior of the physical port:
\input{struct/ofp_port_mod}
The \verb|mask| field is used to select bits in the \verb|config| field to change. The \verb|advertise| field has no mask; all port features change together.
\subsubsection{\qosupd{Queue Configuration Messages}}
\qosupd{Queue configuration takes place outside the OpenFlow protocol, either
through a command line tool or through an external dedicated configuration
protocol.
\\\\
The controller can query the switch for configured queues on a port
using the following structure:
\input{struct/ofp_queue_get_config_request}
The switch replies back with an} \verb|ofp_queue_get_config_reply| \qosupd{command, containing
a list of configured queues.
\input{struct/ofp_queue_get_config_reply}
}
\subsubsection{Read State Messages}
While the system is running, the datapath may be queried about its current state using the \verb|OFPT_STATS_REQUEST| message:
\input{struct/ofp_stats_request}
The switch responds with one or more \verb|OFPT_STATS_REPLY| messages:
\input{struct/ofp_stats_reply}
The only value defined for \verb|flags| in a reply is whether more replies will follow this one - this has the value \verb|0x0001|. To ease implementation, the switch is allowed to send replies with no additional entries. However, it must always send another reply following a message with the �more� flag set. The transaction ids (xid) of replies must always match the request that prompted them.
\\\\
In both the request and response, the \verb|type| field specifies the kind of information being passed and determines how the \verb|body| field is interpreted:
\input{enum/ofp_stats_types}
\paragraph{Description Statistics}
Information about the switch manufacturer, hardware revision, software revision, serial number, and a description field is available from the \verb|OFPST_DESC| stats request type:
\input{struct/ofp_desc_stats}
Each entry is ASCII formatted and padded on the right with null bytes (\textbackslash0). \verb|DESC_STR_LEN| is \input{define/DESC_STR_LEN}and \verb|SERIAL_NUM_LEN| is \input{define/SERIAL_NUM_LEN}. Note: \footnote{Added to address concerns raised in \url{https://mailman.stanford.edu/pipermail/openflow-spec/2009-September/000504.html}} the \verb|dp_desc| field is a free-form string to describe the datapath for debugging purposes, e.g., ``switch3 in room 3120''. As such, it is not guaranteed to be unique and should not be used as the primary identifier for the datapath---use the \verb|datapath_id| field from the switch features instead (\S~\ref{cts:handshake}).
\paragraph{Individual Flow Statistics}
Information about individual flows is requested with the \verb|OFPST_FLOW| stats request type:
\input{struct/ofp_flow_stats_request}
The \verb|match| field contains a description of the flows that should be matched and may contain wildcards. This field's matching behavior is described in Section \ref{flow_table:sec_chan:flow_add}.
\\\\
The \verb|table_id| field indicates the index of a single table to read, or \verb|0xff| for all tables.
\\\\
The \verb|out_port| field optionally filters by output port. If \verb|out_port| 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. Other constraints such as \verb|ofp_match| structs are still used; this is purely an \emph{additional} constraint. Note that to disable output port filtering, \verb|out_port| must be set to \verb|OFPP_NONE|, since 0 is a valid port id.
\\\\
The \verb|body| of the reply consists of an array of the following:
\input{struct/ofp_flow_stats}
The fields consist of those provided in the \verb|flow_mod| that created these, plus the table into which the entry was inserted, the packet count, and the byte count.
\\\\
\label{flow_duration_info}The \verb|duration_sec| and \verb|duration_nsec| fields indicate the elapsed time the flow has been installed in the switch. The total duration in nanoseconds can be computed as $\verb|duration_sec|*10^{9}$ + \verb|duration_nsec|. Implementations are required to provide millisecond precision; higher precision is encouraged where available.
\paragraph{Aggregate Flow Statistics}
Aggregate information about multiple flows is requested with the \verb|OFPST_AGGREGATE| stats request type:
\input{struct/ofp_aggregate_stats_request}
The \verb|match| field contains a description of the flows that should be matched and may contain wildcards. This field's matching behavior is described in Section \ref{flow_table:sec_chan:flow_add}.
\\\\
The \verb|table_id| field indicates the index of a single table to read, or \verb|0xff| for all tables.
\\\\
The \verb|out_port| field optionally filters by output port. If \verb|out_port| 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. Other constraints such as \verb|ofp_match| structs are still used; this is purely an \emph{additional} constraint. Note that to disable output port filtering, \verb|out_port| must be set to \verb|OFPP_NONE|, since 0 is a valid port id.
\\\\
The \verb|body| of the reply consists of the following:
\input{struct/ofp_aggregate_stats_reply}
\paragraph{Table Statistics}
Information about tables is requested with the \verb|OFPST_TABLE| stats request type. The request does not contain any data in the body.
\\\\
The body of the reply consists of an array of the following:
\input{struct/ofp_table_stats}
The \verb|body| contains a \verb|wildcards| field, which indicates the fields for which that particular table supports wildcarding. For example, a direct look-up hash table would have that field set to zero, while a sequentially searched table would have it set to \verb|OFPFW_ALL|. The entries are returned in the order that packets traverse the tables.
\\\\
\verb|OFP_MAX_TABLE_NAME_LEN| is \input{define/OFP_MAX_TABLE_NAME_LEN}.
\paragraph{Port Statistics}
Information about physical ports is requested with the \verb|OFPST_PORT| stats request type:
\input{struct/ofp_port_stats_request}
The \verb|port_no| field optionally filters the stats request to the given port. To request all port statistics, \verb|port_no| must be set to \verb|OFPP_NONE|.
\\\\
The \verb|body| of the reply consists of an array of the following:
\input{struct/ofp_port_stats}
The switch should return a value of -1 for unavailable counters.
\paragraph{\qosupd{Queue Statistics}}
\qosupd{The} \verb|OFPST_QUEUE| \qosupd{stats request message provides
queue statistics for one or more ports.
The request body consists of a} \verb|port_no| \qosupd{field
identifying the port and a} \verb|queue_id|. \verb|OFPP_ALL|
\qosupd{refers to all ports, while} \verb|OFPQ_ALL| \qosupd{refers to all queues configured
at a port.
\input{struct/ofp_queue_stats_request}
The body of the reply consists of an array of
the following structure:
\input{struct/ofp_queue_stats}}
\paragraph{Vendor Statistics}
Vendor-specific stats messages are requested with the \verb|OFPST_VENDOR| stats type. The first four bytes of the message are the vendor identifier. The rest of the body is vendor-defined.
\\\\
The \verb|vendor| field is a 32-bit value that uniquely identifies the vendor. If the most significant byte is zero, the next three bytes are the vendor's IEEE OUI. If vendor does not have (or wish to use) their OUI, they should contact the OpenFlow consortium to obtain one.
\subsubsection{Send Packet Message}
When the controller wishes to send a packet out through the datapath, it uses the \verb|OFPT_PACKET_OUT| message:
\input{struct/ofp_packet_out}
The \verb|buffer_id| is the same given in the \verb|ofp_packet_in| message. If the \verb|buffer_id| is -1, then the packet data is included in the data array. If \verb|OFPP_TABLE| is specified as the output port of an action, the \verb|in_port| in the \verb|packet_out| message is used in the flow table lookup.
\subsubsection{Barrier Message}
When the controller wants to ensure message dependencies have been met or wants to receive notifications for completed operations, it may use an \verb|OFPT_BARRIER_REQUEST| message. This message has no body. Upon receipt, the switch must finish processing all previously-received messages before executing any messages beyond the Barrier Request. When such processing is complete, the switch must send an \verb|OFPT_BARRIER_REPLY| message with the \verb|xid| of the original request.
\subsection{Asynchronous Messages}
\subsubsection{Packet-In Message}
When packets are received by the datapath and sent to the controller, they use the \verb|OFPT_PACKET_IN| message:
\input{struct/ofp_packet_in}
The \verb|buffer_id| is an opaque value used by the datapath to identify a buffered packet. When a packet is buffered, some number of bytes from the message will be included in the data portion of the message. If the packet is sent because of a ``send to controller'' action, then \verb|max_len| bytes from the \verb|action_output| of the flow setup request are sent. If the packet is sent because of a flow table miss, then at least \verb|miss_send_len| bytes from the \verb|OFPT_SET_CONFIG| message are sent. The default \verb|miss_send_len| is \input{define/OFP_DEFAULT_MISS_SEND_LEN}bytes. If the packet is not buffered, the entire packet is included in the data portion, and the \verb|buffer_id| is -1.
\\\\
Switches that implement buffering are expected to expose, through documentation, both the amount of available buffering, and the length of time before buffers may be reused. A switch must gracefully handle the case where a buffered \verb|packet_in| message yields no response from the controller. A switch should prevent a buffer from being reused until it has been handled by the controller, or some amount of time (indicated in documentation) has passed.
\\\\
The reason field can be any of these values:
\input{enum/ofp_packet_in_reason}
\subsubsection{Flow Removed Message}
If the controller has requested to be notified when flows time out, the datapath does this with the \verb|OFPT_FLOW_REMOVED| message:
\input{struct/ofp_flow_removed}
The \verb|match|, \verb|cookie|, and \verb|priority| fields are the same as those used in the flow setup request.
\\\\
The \verb|reason| field is one of the following:
\input{enum/ofp_flow_removed_reason}
The \verb|duration_sec| and \verb|duration_nsec| fields are described in Section \ref{flow_duration_info}.
\\\\
The \verb|idle_timeout| field is directly copied from the flow mod that created this entry.
\\\\
With the above three fields, one can find both the amount of time the flow was active, as well as the amount of time the flow received traffic.
\\\\
The \verb|packet_count| and \verb|byte_count| indicate the number of packets and bytes that were associated with this flow, respectively.
\subsubsection{Port Status Message}
As physical ports are added, modified, and removed from the datapath, the controller needs to be informed with the \verb|OFPT_PORT_STATUS| message:
\input{struct/ofp_port_status}
The \verb|status| can be one of the following values:
\input{enum/ofp_port_reason}
\subsubsection{Error Message}
There are times that the switch needs to notify the controller of a problem. This is done with the \verb|OFPT_ERROR_MSG| message:
\input{struct/ofp_error_msg}
The \verb|type| value indicates the high-level type of error. The \verb|code| value is interpreted based on the type. The \verb|data| is variable length and interpreted based on the \verb|type| and \verb|code|; in most cases this is the message that caused the problem.
\\\\
Error codes ending in \verb|_EPERM| correspond to a permissions error generated by an entity between a controller and switch, such as an OpenFlow hypervisor.
\\\\
Currently defined error types are:
\input{enum/ofp_error_type}
For the \verb|OFPET_HELLO_FAILED| error \verb|type|, the following \verb|code|s are currently defined:
\input{enum/ofp_hello_failed_code}
The \verb|data| field contains an ASCII text string that adds detail on why the error occurred.
\\\\
For the \verb|OFPET_BAD_REQUEST| error \verb|type|, the following \verb|code|s are currently defined:
\input{enum/ofp_bad_request_code}
The \verb|data| field contains at least 64 bytes of the failed request.
\\\\
For the \verb|OFPET_BAD_ACTION| error \verb|type|, the following \verb|code|s are currently defined:
\input{enum/ofp_bad_action_code}
The \verb|data| field contains at least 64 bytes of the failed request.
\\\\
For the \verb|OFPET_FLOW_MOD_FAILED| error \verb|type|, the following \verb|code|s are currently defined:
\input{enum/ofp_flow_mod_failed_code}
The \verb|data| field contains at least 64 bytes of the failed request.
\\\\
For the \verb|OFPET_PORT_MOD_FAILED| error \verb|type|, the following \verb|code|s are currently defined:
\input{enum/ofp_port_mod_failed_code}
The \verb|data| field contains at least 64 bytes of the failed request.
\\\\
For the \verb|OFPET_QUEUE_OP_FAILED| error \verb|type|, the following \verb|code|s are currently defined:
\input{enum/ofp_queue_op_failed_code}
The \verb|data| field contains at least 64 bytes of the failed request.
\\\\
If the error message is in response to a specific message from the controller, e.g., \verb|OFPET_BAD_REQUEST|, \verb|OFPET_BAD_ACTION|, or \verb|OFPET_FLOW_MOD_FAILED|, then the \verb|xid| field of the header should match that of the offending message.
\subsection{Symmetric Messages}
\subsubsection{Hello}
The \verb|OFPT_HELLO| message has no body; that is, it consists only of an OpenFlow header. Implementations must be prepared to receive a hello message that includes a body, ignoring its contents, to allow for later extensions.
\subsubsection{Echo Request}
An Echo Request message consists of an OpenFlow header plus an arbitrary-length data field. The data field might be a message timestamp to check latency, various lengths to measure bandwidth, or zero-size to verify liveness between the switch and controller.
\subsubsection{Echo Reply}
An Echo Reply message consists of an OpenFlow header plus the unmodified data field of an echo request message.
\\\\
In an OpenFlow protocol implementation divided into multiple layers, the echo request/reply logic should be implemented in the "deepest" practical layer. For example, in the OpenFlow reference implementation that includes a userspace process that relays to a kernel module, echo request/reply is implemented in the kernel module. Receiving a correctly formatted echo reply then shows a greater likelihood of correct end-to-end functionality than if the echo request/reply were implemented in the userspace process, as well as providing more accurate end-to-end latency timing.
\subsubsection{Vendor}
The Vendor message is defined as follows:
\input{struct/ofp_vendor_header}
The \verb|vendor| field is a 32-bit value that uniquely identifies the vendor. If the most significant byte is zero, the next three bytes are the vendor's IEEE OUI. If vendor does not have (or wish to use) their OUI, they should contact the OpenFlow consortium to obtain one. The rest of the body is uninterpreted.
\\\\
If a switch does not understand a vendor extension, it must send an \verb|OFPT_ERROR| message with a \verb|OFPBRC_BAD_VENDOR| error code and \verb|OFPET_BAD_REQUEST| error type.
Reference in new issue View Git Blame Copy Permalink