\documentclass[10pt]{article} \usepackage{amsmath} \usepackage{listings} \usepackage{hyperref} \usepackage{fancyhdr} \usepackage{graphicx} \usepackage{tabularx} \usepackage{color} \hbadness=10000 % No "underfull hbox" messages \begin{document} %\lstset{language=C} % Define the OpenFlow version here \newcommand{\ofversion}{1.0.0} \pagestyle{fancy} \fancyhead{} \lhead{OpenFlow Switch Specification} %\chead{DO NOT BUILD A SWITCH FROM THIS SPECIFICATION!} \rhead{Version \ofversion} \renewcommand{\headrulewidth}{0.4pt} \renewcommand{\footrulewidth}{0.4pt} \fontfamily{cmr} % what about cmss? \selectfont \newcommand{\qosupd}[1]{{#1}} %\newcommand{\qosupd}[1]{{\color{blue} #1}} \title{OpenFlow Switch Specification} \author{Version \ofversion{} ( Wire Protocol \input{define/OFP_VERSION})} \date{\today} \maketitle \section{Introduction} This document describes the requirements of an OpenFlow Switch. We recommend that you read the latest version of the OpenFlow whitepaper before reading this specification. The whitepaper is available on the OpenFlow Consortium website (\url{http://OpenFlowSwitch.org}). This specification covers the components and the basic functions of the switch, and the OpenFlow protocol to manage an OpenFlow switch from a remote controller. \\\\ Version 1.0 of this document will be the first for which official vendor support is expected. Versions before 1.0 will be marked ``Draft", and will include the header: ``Do not build a switch from this specification!" We hope to generate feedback prior to Version 1.0 from switch designers and network researchers, so that the set of features defined in Version 1.0 enables production deployments on a variety of vendor hardware. \begin{figure}[htbp] \centering \includegraphics[height=2.5in]{figure_flow_table_secchan.png} \caption{An OpenFlow switch communicates with a controller over a secure connection using the OpenFlow protocol.} \label{fig:flow table and controller} \end{figure} \section{Switch Components} An OpenFlow Switch consists of a \emph{flow table}, which performs packet lookup and forwarding, and a \emph{secure channel} to an external controller (Figure \ref{fig:flow table and controller}). The controller manages the switch over the secure channel using the OpenFlow protocol. \\\\ The flow table contains a set of flow entries (header values to match packets against), activity counters, and a set of zero or more actions to apply to matching packets. All packets processed by the switch are compared against the flow table. If a matching entry is found, any actions for that entry are performed on the packet (e.g., the action might be to forward a packet out a specified port). If no match is found, the packet is forwarded to the controller over the secure channel. The controller is responsible for determining how to handle packets without valid flow entries, and it manages the switch flow table by adding and removing flow entries. \\\\ Flow entries may forward packets to one or more OpenFlow ports. In general, these are physical ports, but the protocol does not preclude abstractions like port aggregations or VLAN traffic on a port appearing as an OpenFlow port. OpenFlow ports have limited state such as ``up'', ``down'' and whether spanning tree flood packets should be forwarded out the port. Additional configuration of ports may handled by the OpenFlow configuration protocol. There are several OpenFlow virtual ports used to indicate, for example, flooding or the ingress port (see \ref{ft:actions}). \section{Flow Table} This section describes the components of flow table entries and the process by which incoming packets are matched against flow table entries. \begin{table}[hbp] \centering \begin{tabular}{|c|c|c|} \hline Header Fields & Counters & Actions\\ \hline \end{tabular} \caption{A flow entry consists of header fields, counters, and actions.} \label{table:flow entry} \end{table} Each flow table entry (see Table \ref{table:flow entry}) contains: \begin{itemize} \item \textbf{header fields} to match against packets \item \textbf{counters} to update for matching packet \item \textbf{actions} to apply to matching packets \end{itemize} \subsection{Header Fields} \begin{table}[hbp] \centering \footnotesize \begin{tabularx}{\textwidth}{ |X|X|X|X|X|X|X|X|X|X|X|X| } \hline Ingress Port & Ether source & Ether dst & Ether type & VLAN id & VLAN priority & IP src & IP dst & IP proto & IP ToS bits & TCP/ UDP src port & TCP/ UDP dst port \\ \hline \end{tabularx} \caption{Fields from packets used to match against flow entries.} \label{table:header fields} \end{table} Table \ref{table:header fields} shows the header fields an incoming packet is compared against. Each entry contains a specific value, or ANY, which matches any value. If the switch supports subnet masks on the IP source and/or destination fields, these can more precisely specify matches. The fields in the OpenFlow 12-tuple are listed in Table \ref{table:header fields} and details on the properties of each field are described in Table \ref{table:header field details}. \\\\ \begin{table}[hbp] \centering \footnotesize \begin{tabularx}{\textwidth}{ |X|X|X|X| } \hline Field & Bits & When applicable & Notes \\ \hline Ingress Port & (Implementation dependent) & All packets & Numerical representation of incoming port, starting at 1. \\ \hline Ethernet source address & 48 & All packets on enabled ports & \\ \hline Ethernet destination address & 48 & All packets on enabled ports & \\ \hline Ethernet type & 16 & All packets on enabled ports & An OpenFlow switch is required to match the type in both standard Ethernet and 802.2 with a SNAP header and OUI of 0x000000. The special value of 0x05FF is used to match all 802.3 packets without SNAP headers. \\ \hline VLAN id & 12 & All packets of Ethernet type 0x8100 & \\ \hline VLAN priority & 3 & All packets of Ethernet type 0x8100 & VLAN PCP field \\ \hline IP source address & 32 & All IP and ARP packets & Can be subnet masked \\ \hline IP destination address & 32 & All IP and ARP packets & Can be subnet masked \\ \hline IP protocol & 8 & All IP and IP over Ethernet, ARP packets & Only the lower 8 bits of the ARP opcode are used \\ \hline IP ToS bits & 6 & All IP packets & Specify as 8-bit value and place ToS in upper 6 bits. \\ \hline Transport source port / ICMP Type & 16 & All TCP, UDP, and ICMP packets & Only lower 8 bits used for ICMP Type \\ \hline Transport destination port / ICMP Code & 16 & All TCP, UDP, and ICMP packets & Only lower 8 bits used for ICMP Code \\ \hline \end{tabularx} \caption{Field lengths and the way they must be applied to flow entries.} \label{table:header field details} \end{table}Switch designers are free to implement the internals in any way convenient provided that correct functionality is preserved. For example, while a flow may have multiple forward actions, each specifying a different port, a switch designer may choose to implement this as a single bitmask within the hardware forwarding table. \subsection{Counters} Counters are maintained per-table, per-flow, \qosupd{per-port and per queue}. OpenFlow-compliant counters may be implemented in software and maintained by polling hardware counters with more limited ranges. \\\\ Table \ref{table:counters} contains the required set of counters. Duration refers to the time the flow has been installed in the switch. The Receive Errors field includes all explicitly specified errors, including frame, overrun, and CRC errors, plus any others. Counters wrap around with no overflow indicator. In this document, the phrase byte refers to 8-bit octets. \begin{table}[!hbp] \centering \footnotesize %\begin{tabularx}{\textwidth}{ |X|X| } \begin{tabular}{ |l|c| } \hline Counter & Bits \\ \hline \multicolumn{2}{|c|}{Per Table} \\ \hline Active Entries & 32 \\ \hline Packet Lookups & 64 \\ \hline Packet Matches & 64 \\ \hline \multicolumn{2}{|c|}{Per Flow} \\ \hline Received Packets & 64 \\ \hline Received Bytes & 64 \\ \hline Duration (seconds) & 32 \\ \hline Duration (nanoseconds) & 32 \\ \hline \multicolumn{2}{|c|}{Per Port} \\ \hline Received Packets & 64 \\ \hline Transmitted Packets & 64 \\ \hline Received Bytes & 64 \\ \hline Transmitted Bytes & 64 \\ \hline Receive Drops & 64 \\ \hline Transmit Drops & 64 \\ \hline Receive Errors & 64 \\ \hline Transmit Errors & 64 \\ \hline Receive Frame Alignment Errors & 64 \\ \hline Receive Overrun Errors & 64 \\ \hline Receive CRC Errors & 64 \\ \hline Collisions & 64 \\ \hline \multicolumn{2}{|c|}{\qosupd{Per Queue}} \\ \hline \qosupd{Transmit Packets} & \qosupd{64} \\ \hline \qosupd{Transmit Bytes} & \qosupd{64} \\ \hline \qosupd{Transmit Overrun Errors} & \qosupd{64}\\ \hline \end{tabular} \caption{Required list of counters for use in statistics messages.} \label{table:counters} \end{table} \subsection{Actions} \label{ft:actions} 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}. \\\\ OpenFlow-only switches support only the required actions below, while OpenFlow-enabled switches, routers, and access points may also support the \textbf{NORMAL} action. Either type of switch can also support the \textbf{FLOOD} action. \\\\ \textbf{Required Action:} \textit{Forward}. OpenFlow switches must support forwarding the packet to physical ports and the following virtual ones: \begin{itemize} \item \textbf{ALL:} Send the packet out all interfaces, not including the incoming interface. \item \textbf{CONTROLLER:} Encapsulate and send the packet to the controller. \item \textbf{LOCAL:} Send the packet to the switchÕs local networking stack. \item \textbf{TABLE:} Perform actions in flow table. Only for packet-out messages. \item \textbf{IN\_PORT:} Send the packet out the input port. \end{itemize} \textbf{Optional Action:} \textit{Forward}. The switch may optionally support the following virtual ports: \begin{itemize} \item \textbf{NORMAL:} Process the packet using the traditional forwarding path supported by the switch (i.e., traditional L2, VLAN, and L3 processing.) The switch may check the VLAN field to determine whether or not to forward the packet along the normal processing route. If the switch cannot forward entries for the OpenFlow-specific VLAN back to the normal processing route, it must indicate that it does not support this action. \item \textbf{FLOOD:} Flood the packet along the minimum spanning tree, not including the incoming interface. \end{itemize} The controller will only ask the switch to send to multiple physical ports simultaneously if the switch indicates it supports this behavior in the initial handshake (see section \ref{cts:handshake}). \\\\ \textbf{\qosupd{Optional Action:}} \emph{\qosupd{Enqueue}}. \qosupd{The enqueue action forwards a packet through a queue attached to a port. Forwarding behavior is dictated by the configuration of the queue and is used to provide basic Quality-of-Service (QoS) support (see section \ref{cts:qos}).} \\\\ \textbf{Required Action:} \emph{Drop}. A flow-entry with no specified action indicates that all matching packets should be dropped. \\\\ \textbf{Optional Action:} \emph{Modify-Field}. While not strictly required, the actions shown in Table \ref{table:field modify actions} greatly increase the usefulness of an OpenFlow implementation. To aid integration with existing networks, we suggest that VLAN modification actions be supported. \begin{table}[hbp] \centering \footnotesize \begin{tabularx}{\linewidth}{ |X|X|X| } \hline Action & Associated Data & Description \\ \hline Set VLAN ID & 12 bits & If no VLAN is present, a new header is added with the specified VLAN ID and priority of zero. If a VLAN header already exists, the VLAN ID is replaced with the specified value. \\ \hline Set VLAN priority & 3 bits & If no VLAN is present, a new header is added with the specified priority and a VLAN ID of zero. If a VLAN header already exists, the priority field is replaced with the specified value. \\ \hline Strip VLAN header & - & Strip VLAN header if present. \\ \hline Modify Ethernet source MAC address & 48 bits: Value with which to replace existing source MAC address & Replace the existing Ethernet source MAC address with the new value \\ \hline Modify Ethernet destination MAC address & 48 bits: Value with which to replace existing destination MAC address & Replace the existing Ethernet destination MAC address with the new value. \\ \hline Modify IPv4 source address & 32 bits: Value with which to replace existing IPv4 source address & Replace the existing IP source address with new value and update the IP checksum (and TCP/UDP checksum if applicable). This action is only applicable to IPv4 packets. \\ \hline Modify IPv4 destination address & 32 bits: Value with which to replace existing IPv4 destination address & Replace the existing IP destination address with new value and update the IP checksum (and TCP/UDP checksum if applicable). This action is only applied to IPv4 packets. \\ \hline Modify IPv4 ToS bits & 6 bits: Value with which to replace existing IPv4 ToS field & Replace the existing IP ToS field. This action is only applied to IPv4 packets. \\ \hline Modify transport source port & 16 bits: Value with which to replace existing TCP or UDP source port & Replace the existing TCP/UDP source port with new value and update the TCP/UDP checksum. This action is only applicable to TCP and UDP packets.\\ \hline Modify transport destination port & 16 bits: Value with which to replace existing TCP or UDP destination port & Replace the existing TCP/UDP destination port with new value and update the TCP/UDP checksum This action is only applied to TCP and UDP packets.\\ \hline \end{tabularx} \caption{Field-modify actions.} \label{table:field modify actions} \end{table} \subsection{Matching} \begin{figure}[!htb] \centering \includegraphics[height=1.85in]{packet_flow_flowchart} \caption{Packet flow in an OpenFlow switch. As discussed in Section \ref{flow_table:stp_support}, support for 802.1D is optional.} \label{fig:packet_flow} \end{figure} \begin{figure}[!htb] \centering \includegraphics[height=2.9in]{header_parsing_flowchart} \caption{Flowchart showing how header fields are parsed for matching.} \label{fig:header_parsing} \end{figure} On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure \ref{fig:packet_flow}. Header fields used for the table lookup depend on the packet type as described below (and shown in Figure \ref{fig:header_parsing}). \begin{itemize} \item Rules specifying an ingress port are matched against the physical port that received the packet. \item The Ethernet headers as specified in Table \ref{table:header fields} are used for all packets. \item If the packet is a VLAN (Ethernet type 0x8100), the VLAN ID and PCP fields are used in the lookup. \item (Optional) For ARP packets (Ethernet type equal to 0x0806), the lookup fields may also include the contained IP source and destination fields. \item For IP packets (Ethernet type equal to 0x0800), the lookup fields also include those in the IP header. \item For IP packets that are TCP or UDP (IP protocol is equal to 6 or 17), the lookup includes the transport ports. \item For IP packets that are ICMP (IP prototcol is equal to 1), the lookup includes the Type and Code fields. \item For IP packets with nonzero fragment offset or More Fragments bit set, the transport ports are set to zero for the lookup. \end{itemize} A packet matches a flow table entry if the values in the header fields used for the lookup (as defined above) match those defined in the flow table. If a flow table field has a value of ANY, it matches all possible values in the header. \\\\ To handle the various Ethernet framing types, matching the Ethernet type is handled in a slightly different manner. If the packet is an Ethernet II frame, the Ethernet type is handled in the expected way. If the packet is an 802.3 frame with a SNAP header and Organizationally Unique Identifier (OUI) of 0x000000, the SNAP protocol id is matched against the flowÕs Ethernet type. A flow entry that specifies an Ethernet type of 0x05FF, matches all Ethernet 802.2 frames without a SNAP header and those with SNAP headers that do not have an OUI of 0x000000. \\\\ Packets are matched against flow entries based on prioritization. An entry that specifies an exact match (i.e., it has no wildcards) is always the highest priority. All wildcard entries have a priority associated with them. Higher priority entries must match before lower priority ones. If multiple entries have the same priority, the switch is free to choose any ordering. Higher numbers have higher priorities. \\\\ For each packet that matches a flow entry, the associated counters for that entry are updated. If no matching entry can be found for a packet, the packet is sent to the controller over the secure channel. \section{Secure Channel} The secure channel is the interface that connects each OpenFlow switch to a controller. Through this interface, the controller configures and manages the switch, receives events from the switch, and send packets out the switch. \\\\ Between the datapath and the secure channel, the interface is implementation-specific, however all secure channel messages must be formatted according to the OpenFlow protocol. \\\\ Support for multiple simultaneous controllers is currently undefined. \subsection{OpenFlow Protocol Overview} The OpenFlow protocol supports three message types, \emph{controller-to-switch}, \emph{asynchronous}, and \emph{symmetric}, each with multiple sub-types. Controller-to-switch messages are initiated by the controller and used to directly manage or inspect the state of the switch. Asynchronous messages are initiated by the switch and used to update the controller of network events and changes to the switch state. Symmetric messages are initiated by either the switch or the controller and sent without solicitation. The message types used by OpenFlow are described below. \subsubsection{Controller-to-Switch} Controller/switch messages are initiated by the controller and may or may not require a response from the switch. \\\\ \textbf{Features:} Upon Transport Layer Security (TLS) session establishment, the controller sends a features request message to the switch. The switch must reply with a features reply that specifies the capabilities supported by the switch. \\\\ \textbf{Configuration:} The controller is able to set and query configuration parameters in the switch. The switch only responds to a query from the controller. \\\\ \textbf{Modify-State:} Modify-State messages are sent by the controller to manage state on the switches. Their primary purpose is to add/delete and modify flows in the flow tables and to set switch port properties. \\\\ \textbf{Read-State:} Read-State messages are used by the controller to collect statistics from the switchÕs flow-tables, ports and the individual flow entries. \\\\\ \textbf{Send-Packet}: These are used by the controller to send packets out of a specified port on the switch. \\\\ \textbf{Barrier}: Barrier request/reply messages are used by the controller to ensure message dependencies have been met or to receive notifications for completed operations. \subsubsection{Asynchronous} Asynchronous messages are sent without the controller soliciting them from a switch. Switches send asynchronous messages to the controller to denote a packet arrival, switch state change, or error. The four main asynchronous message types are described below. \\\\ \textbf{Packet-in:} For all packets that do not have a matching flow entry, a packet-in event is sent to the controller (or if a packet matches an entry with a ``send to controller" action). If the switch has sufficient memory to buffer packets that are sent to the controller, the packet-in events contain some fraction of the packet header (by default \input{define/OFP_DEFAULT_MISS_SEND_LEN} bytes) and a buffer ID to be used by the controller when it is ready for the switch to forward the packet. Switches that do not support internal buffering (or have run out of internal buffering) must send the full packet to the controller as part of the event. \\\\ \textbf{Flow-Removed:} When a flow entry is added to the switch by a flow modify message, an idle timeout value indicates when the entry should be removed due to a lack of activity, as well as a hard timeout value that indicates when the entry should be removed, regardless of activity. The flow modify message also specifies whether the switch should send a flow removed message to the controller when the flow expires. Flow modify messages which delete flows may also cause flow removed messages. \\\\ \textbf{Port-status:} The switch is expected to send port-status messages to the controller as port configuration state changes. These events include change in port status (for example, if it was brought down directly by a user) or a change in port status as specified by 802.1D (see Section \ref{flow_table:stp_support} for a description of 802.1D support requirements). \\\\ \textbf{Error:} The switch is able to notify the controller of problems using error messages. \subsubsection{Symmetric} Symmetric messages are sent without solicitation, in either direction. \\\\ \textbf{Hello:} Hello messages are exchanged between the switch and controller upon connection startup. \\\\ \textbf{Echo:} Echo request/reply messages can be sent from either the switch or the controller, and must return an echo reply. They can be used to indicate the latency, bandwidth, and/or liveness of a controller-switch connection. \\\\ \textbf{Vendor:} Vendor messages provide a standard way for OpenFlow switches to offer additional functionality within the OpenFlow message type space. This is a staging area for features meant for future OpenFlow revisions. \subsection{Connection Setup} The switch must be able to establish the communication at a user-configurable (but otherwise fixed) IP address, using a user-specified port. Traffic to and from the secure channel is not checked against the flow table. Therefore, the switch must identify incoming traffic as local before checking it against the flow table. Future versions of the protocol specification will describe a dynamic controller discovery protocol in which the IP address and port for communicating with the controller is determined at runtime. \\\\ When an OpenFlow connection is first established, each side of the connection must immediately send an \verb|OFPT_HELLO| message with the \verb|version| field set to the highest OpenFlow protocol version supported by the sender. Upon receipt of this message, the recipient may calculate the OpenFlow protocol version to be used as the smaller of the version number that it sent and the one that it received. \\\\ If the negotiated version is supported by the recipient, then the connection proceeds. Otherwise, the recipient must reply with an \verb|OFPT_ERROR| message with a \verb|type| field of \verb|OFPET_HELLO_FAILED|, a \verb|code| field of \verb| OFPHFC_COMPATIBLE|, and optionally an ASCII string explaining the situation in \verb|data|, and then terminate the connection. \subsection{Connection Interruption} In the case that a switch loses contact with the controller, as a result of a echo request timeout, TLS session timeout, or other disconnection, it should attempt to contact one or more backup controllers. The ordering of the controller IP addresses is not specified by the protocol. \\\\ If some number of attempts to contact a controller (zero or more) fail, the switch must enter ``emergency mode'' and immediately reset the current TCP connection. In emergency mode, the matching process is dictated by the emergency flow table entries (those marked with the emergency bit when added to the switch). All normal entries are deleted when entering emergency mode. \\\\ Upon connecting to a controller again, the emergency flow entries remain. The controller then has the option of deleting all flow entries, if desired. \\\\ The first time a switch starts up, it is considered to be in emergency mode. Configuration of the default set of flow entries is outside the scope of the OpenFlow protocol. \subsection{Encryption} The switch and controller communicate through a TLS connection. The TLS connection is initiated by the switch on startup to the controller's server, which is located by default on TCP port \input{define/OFP_TCP_PORT}. The switch and controller mutually authenticate by exchanging certificates signed by a site-specific private key. Each switch must be user-configurable with one certificate for authenticating the controller (controller certificate) and the other for authenticating to the controller (switch certificate). \subsection{Spanning Tree} \label{flow_table:stp_support} OpenFlow switches may optionally support 802.1D Spanning Tree Protocol. Those switches that do support it are expected to process all 802.1D packets locally before performing flow lookup. A switch that implements STP must set the \verb|OFPC_STP| bit in the 'capabilities' field of its \verb|OFPT_FEATURES_REPLY| message. A switch that implements STP must make it available on all of its physical ports, but it need not implement it on virtual ports (e.g. \verb|OFPP_LOCAL|). \\\\ Port status, as specified by the spanning tree protocol, is then used to limit packets forwarded to the \verb|OFP_FLOOD| port to only those ports along the spanning tree. Port changes as a result of the spanning tree are sent to the controller via port-update messages. Note that forward actions that specify the outgoing port or \verb|OFP_ALL| ignore the port status set by the spanning tree protocol. Packets received on ports that are disabled by spanning tree must follow the normal flow table processing path. \\\\ Switches that do not support 802.1D spanning tree must allow the controller to specify the port status for packet flooding through the port-mod messages. \subsection{Flow Table Modification Messages} \label{flow_table:sec_chan:flow_add} \label{flow_table:sec_chan:flow_mod} \label{flow_table:sec_chan:flow_removal} Flow table modification messages can have the following types: \input{enum/ofp_flow_mod_command} For ADD requests with the \verb|OFPFF_CHECK_OVERLAP| flag set, the switch must first check for any overlapping flow entries. Two flow entries overlap if a single packet may match both, and both entries have the same priority. If an overlap conflict exists between an existing flow entry and the ADD request, the switch must refuse the addition and respond with an \verb|ofp_error_msg| with \verb|OFPET_FLOW_MOD_FAILED| type and \verb|OFPFMFC_OVERLAP| code. \\\\ For valid (non-overlapping) ADD requests, or those with no overlap checking, the switch must insert the flow entry at the lowest numbered table for which the switch supports all wildcards set in the \verb|flow_match| struct, and for which the priority would be observed during the matching process. If a flow entry with identical header fields and priority already resides in any table, then that entry, including its counters, must be removed, and the new flow entry added. \\\\ If a switch cannot find any table in which to add the incoming flow entry, the switch should send an \verb|ofp_error_msg| with \verb|OFPET_FLOW_MOD_FAILED| type and \verb|OFPFMFC_ALL_TABLES_FULL| code. \\\\ If the action list in a flow mod message references a port that will never be valid on a switch, the switch must return an \verb|ofp_error_msg| with \verb|OFPET_BAD_ACTION| type and \verb|OFPBAC_BAD_OUT_PORT| code. If the referenced port may be valid in the future, e.g. when a linecard is added to a chassis switch, or a port is dynamically added to a software switch, the switch may either silently drop packets sent to the referenced port, or immediately return an \verb|OFPBAC_BAD_OUT_PORT| error and refuse the flow mod. \\\\ For MODIFY requests, if a flow entry with identical header fields does not current reside in any table, the MODIFY acts like an ADD, and the new flow entry must be inserted with zeroed counters. Otherwise, the actions field is changed on the existing entry and its counters and idle time fields are left unchanged. \\\\ For DELETE requests, if no flow entry matches, no error is recorded, and no flow table modification occurs. If flow entries match, and must be deleted, then each normal entry with the \verb|OFPFF_SEND_FLOW_REM| flag set should generate a flow removed message. Deleted emergency flow entries generate no flow removed messages. \\\\ MODIFY and DELETE flow mod commands have corresponding \_STRICT versions. Without \_STRICT appended, the wildcards are active and all flows that match the description are modified or removed. If \_STRICT is appended, all fields, including the wildcards and priority, are strictly matched against the entry, and only an identical flow is modified or removed. For example, if a message to remove entries is sent that has all the wildcard flags set, the DELETE command would delete all flows from all tables, while the DELETE\_STRICT command would only delete a rule that applies to all packets at the specified priority. \\\\ For non-strict MODIFY and DELETE commands that contain wildcards, a match will occur when a flow entry exactly matches or is more specific than the description in the flow\_mod command. For example, if a DELETE command says to delete all flows with a destination port of 80, then a flow entry that is all wildcards will not be deleted. However, a DELETE command that is all wildcards will delete an entry that matches all port 80 traffic. This same interpretation of mixed wildcard and exact header fields also applies to individual and aggregate flows stats. \\\\ 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} Each flow entry has an \verb|idle_timeout| and a \verb|hard_timeout| associated with it. If no packet has matched the rule in the last \verb|idle_timeout| seconds, or it has been \verb|hard_timeout| seconds since the flow was inserted, the switch removes the entry and sends a flow removed message. In addition, the controller is able to actively remove entries by sending a flow message with the \verb|DELETE| or \verb|DELETE_STRICT| command. Like the message used to add the entry, a removal message contains a description, which may include wild cards. \input{appendix} \input{credits} \end{document}