Flow tables can be used for ingress or egress processing (see 5.1). Ingress processing is the main processing that happens when the packet enters the OpenFlow switch, and may involve one or more flow tables. Egress processing is the processing that happens after the determination of the output port, it happens in the context of the output port and may involve zero or more flow tables.
There are few differences between flow table used for ingress and egress processing, the flow entries have the same components (see 5.2), flow table matching is the same (see 5.3) and execution of instructions is the same (see 5.5). Table miss processing is the same (see 5.4), and therefore the controller is strongly advised to set a table-miss flow entry in each egress table to avoid dropped packets. In some cases, a flow table can be reconfigured for ingress or egress processing by changing the first egress table (see 7.3.2).
At the beginning of ingress processing, the action set is empty. Flow tables used for ingress processing can only direct packets via the Goto-Table instruction to ingress flow tables, and can not direct packets to egress flow tables using the Goto-Table instruction. Ingress flow tables usually don’t support the Action Set Output match field, but may support it in some cases.
At the beginning of egress processing, the action set contains only an output action for the current output port. Valid values for that output action are any physical or logical port, or the CONTROLLER or LOCAL reserved ports (see 4.5), other reserved ports must be substituted with their actual value. The values of the pipeline fields are preserved, except for the Action Set Output match field ; for example the initial value of the Metadata match field is the value it had when the packet was sent to egress processing. Flow tables used for egress processing can only direct packets via the Goto-Table instruction to egress flow tables. They must support the Action Set Output match field, to allow flows to be based on the output port context. They must forbid the use of an output action or group action in write-action instruction, so that the packet output port can not be changed. Those restrictions must be advertised in the flow table features (see 7.3.5.18).
The egress tables may optionally support the output action or group action in apply-action instruction. Those actions behave like they do in an ingress table, they forward clones of the packet to the specified ports, those clones must start egress processing from the first egress table (see 5.7). If supported, this can be used for example for selective egress mirroring. A switch should protect itself from packet infinite loops when using output action or group action in egress tables, this mechanism is implementation specific and outside the scope of this specification.
6 OpenFlow Channel and Control Channel
The OpenFlow channel is the interface that connects each OpenFlow Logical Switch to an OpenFlow controller. Through this interface, the controller configures and manages the switch, receives events
Between the datapath and the OpenFlow channel, the interface is implementation-specific, however all OpenFlow channel messages must be formatted according to the OpenFlow switch protocol. The OpenFlow channel is usually encrypted using TLS, but may be run directly over TCP.
6.1 OpenFlow Switch Protocol Overview
The OpenFlow switch protocol supports three message types, controller-to-switch, asynchronous, and 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.
6.1.1 Controller-to-Switch
Controller/switch messages are initiated by the controller and may or may not require a response from the switch.
Features: The controller may request the identity and the basic capabilities of a switch by sending a features request; the switch must respond with a features reply that specifies the identity and basic capabilities of the switch. This is commonly performed upon establishment of the OpenFlow channel. Configuration: The controller is able to set and query configuration parameters in the switch. The switch only responds to a query from the controller.
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 flow/group entries and insert/remove action buckets of group in the OpenFlow tables and to set switch port properties.
Read-State: Read-State messages are used by the controller to collect various information from the switch, such as current configuration, statistics and capabilities. Most Read-State requests and replies are implemented using multipart message sequences (see 7.3.5).
Packet-out: These are used by the controller to send packets out of a specified port on the switch, and to forward packets received via Packet-in messages. Packet-out messages must contain a full packet or a buffer ID referencing a packet stored in the switch. The message must also contain a list of actions to be applied in the order they are specified; an empty list of actions drops the packet.
Barrier: Barrier request/reply messages are used by the controller to ensure message dependencies have been met or to receive notifications for completed operations.
Role-Request: Role-Request messages are used by the controller to set the role of its OpenFlow channel, set its Controller ID, or query these. This is mostly useful when the switch connects to multiple controllers (see 6.3.6).
Asynchronous-Configuration: The Asynchronous-Configuration messages are used by the controller to set an additional filter on the asynchronous messages that it wants to receive on its OpenFlow channel, or to query that filter. This is mostly useful when the switch connects to multiple controllers (see 6.3.6) and commonly performed upon establishment of the OpenFlow channel.
6.1.2 Asynchronous
Asynchronous messages are sent without a controller soliciting them from a switch. Switches send asynchronous messages to controllers to denote a packet arrival or switch state change. The main asynchronous message types are described below.
Packet-in: Transfer the control of a packet to the controller. For all packets forwarded to the CON- TROLLER reserved port using a flow entry or the table-miss flow entry, a packet-in event is always sent to controllers (see 5.8). Other processing, such as TTL checking, may also generate packet-in events to send packets to the controller.
Packet-in events can be configured to buffer packets. For packet-in generated by an output action in a flow entries or group bucket, it can be specified individually in the output action itself (see 7.2.6.1), for other packet-in it can be configured in the switch configuration (see 7.3.2). If the packet-in event is configured to buffer packets and the switch has sufficient memory to buffer them, the packet-in event contain only some fraction of the packet header and a buffer ID to be used by a controller when it is ready for the switch to forward the packet. Switches that do not support internal buffering, are configured to not buffer packets for the packet-in event, or have run out of internal buffering, must send the full packet to controllers as part of the event. Buffered packets will usually be processed via a Packet-outor Flow-mod message from a controller, or automatically expired after some time. If the packet is buffered, the number of bytes of the original packet to include in the packet-in can be configured. By default, it is 128 bytes. For packet-in generated by an output action in a flow entries or group bucket, it can be specified individually in the output action itself (see 7.2.6.1), for other packet-in it can be configured in the switch configuration (see 7.3.2).
Flow-Removed: Inform the controller about the removal of a flow entry from a flow table. Flow- Removed messages are only sent for flow entries with the OFPFF_SEND_FLOW_REM flag set. They are generated as the result of a controller flow delete request or the switch flow expiry process when one of the flow timeouts is exceeded (see 6.5).
Port-status: Inform the controller of a change on a port. The switch is expected to send port-status messages to controllers as port configuration or port state changes. These events include change in port configuration events, for example if it was brought down directly by a user, and port state change events, for example if the link went down.
Role-status: Inform the controller of a change of its role. When a new controller elects itself master, the switch is expected to send role-status messages to the former master controller (see 6.3.6).
Controller-Status: Inform the controller when the status of an OpenFlow channel changes. The switch sends these messages to all controllers when the status of the OpenFlow channel to any switch changes. This can assist failover processing if controllers lose the ability to communicate among themselves. Flow-monitor: Inform the controller of a change in a flow table. A controller may define a set of monitors to track changes in flow tables (see 7.3.5.19).
6.1.3 Symmetric
Symmetric messages are sent without solicitation, in either direction.
Hello: Hello messages are exchanged between the switch and controller upon connection startup. Echo: Echo request/reply messages can be sent from either the switch or the controller, and must return an echo reply. They are mainly used to verify the liveness of a controller-switch connection, and may as well be used to measure its latency or bandwidth.
Error: Error messages are used by the switch or the controller to notify problems to the other side of the connection. They are mostly used by the switch to indicate a failure of a request initiated by the controller.
Experimenter: Experimenter messages provide a standard way for OpenFlow switches to offer addi- tional functionality within the OpenFlow message type space. This is a staging area for features meant for future OpenFlow revisions.