Asynchronous messages are initiated by the switch and are used to update the controller of network events and changes to the switch state. Switches send asynchronous messages to the controller in order to denote a packet arrival, flow removal, port status change, or an error.

• Packet-in: This is used when packets are received by the switch (data path) and are sent to the controller using the OFPT_PACKET_IN message. When a packet is buffered in the switch, 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 max_len bytes are sent, and if the packet is sent due to a flow table miss, then at least miss_send_len bytes are sent. If the packet is not buffered inside the switch, then the entire packet is included in the data portion of the message. Switches that implement buffering are expected to expose the amount of buffering and the length of time before buffers may be reused. An OpenFlow switch must gracefully handle cases where a buffered packet_in message gets no response from the controller.
• Flow-Removed: When flows times out, the OpenFlow switch notifies the controller with the OFPT_FLOW_REMOVED message (if the controller has requested to be notified). The duration_sec and duration_nsec fields of the message indicate the elapsed time for which the flow has been installed in the switch. The total duration, in nanoseconds, can be computed as duration_sec x 109 + duration_nsec. Implementations are required to provide millisecond precision. The idle_timeout field is directly extracted from the FLOW_MOD that created the flow table entry.
• Port-Status: As physical ports are added, modified, and possibly removed from the data path, the controller needs to be informed with the OPFT_PORT_STATUS message. Also, there are cases where the OpenFlow switch needs to notify the controller of a problem. The message includes an error type, error code, and variable-length data that should be interpreted according to the error type and code. In most cases, the data part is the message that caused the problem. There are six types of error. OFPET_HELLO_FAILED indicates that the HELLO protocol failed. OFPET_BAD_REQUEST refers to the case where the request was not understood. Error in action description is indicated by OFPET_BAD_ACTION. If the FLOW_MOD or PORT_MOD requests are failed, then the error type is OFPET_FLOW_MOD_FAILED and OFPET_PORT_MOD_FAILED, respectively. Failure in port queue operations is classified with OFPET_QUEUE_OP_FAILED.