## 5 Design Choices for OpenFlow-Based SDN
### Management of Flow Entries: Proactive vs. Reactive  
We first explain why flow tables in OpenFlow switches are limited in size, and then, we discuss two approaches for flow table entry management. In the SDN architecture, the control plane is responsible for the configuration of the forwarding devices. With OpenFlow, the controller installs flow table entries in the forwarding tables of the switches. As discussed in Section 3, an entry consists of match fields, counters and forwarding actions. The OpenFlow match fields are wildcards that match to specific header fields in the packets. Wildcards are typically installed in ternary content-addressable memory (TCAM) to ensure fast packet matching and forwarding. However, TCAM is very expensive, so that it needs to be small; as a consequence, only a moderate number of flow entries can be accommodated in the flow table. In the following, we will describe two flow management approaches: proactive and reactive flow management. Both variants are not mutually exclusive: it is common in OpenFlow networks to install some flows proactively and the remaining flows reactively. The controller is able to install flow entries permanently and in particular before they are actually needed. This approach is referred to as proactive flow management [78]. However, this approach has a disadvantage: flow tables must hold many entries that might not fit into the expensive TCAM. Figure 9: (**a**) In-band signaling; (**b**) Out-of-band signaling. To cope with small flow tables, flow entries can also be installed reactively, _i.e._, installed on demand. This is illustrated in Figure 10. (1) Packets can arrive at a switch where no corresponding rule is installed in the table, and therefore, the switch cannot forward the packet on its own; (2) The switch notifies the controller about the packet; (3) The controller identifies the path for the packet and installs appropriate rules in all switches along the path; (4) Then, the packets of that flow can be forwarded to their destination. The mechanisms to enable reactive flow management in OpenFlow are based on timeouts. The controller sets an expiry timer that defaults to one second. The switch tracks the duration to the last match for all entries. Unused entries are removed from the switch. When more packets of an expired flow arrive, the controller must be queried for path installation again. Both flow management approaches have different advantages and disadvantages. The reactive approach holds only the recently used flow entries in the table. On the one hand, this allows one to cope with small forwarding tables. On the other hand, controller interaction is required if packets of a flow arrive in a switch that has no appropriate entry in the flow table. After some time, the correct entry will be eventually installed in the switch, so that packets can be forwarded. The resulting delay depends on the control channel and the current load of the controller. Thus, reactive flow management reduces the state in the switches and relaxes the need for large flow tables, but it increases the delay and reliability requirements of the control channel and control plane software. Especially, failures of the control channel or the controller will have significant impact on the network performance if flow entries cannot be installed in a timely manner. With a proactive flow management approach, all required flow entries are installed in the switches by the controller. Depending on the use case and network, a huge amount of flows must be installed in switches, e.g., BGP routing tables can contain hundreds of thousands IP prefixes. This may require switch memory hierarchy optimizations that are not needed with reactive flow management. While proactive flow management increases state requirements in switches, it relaxes the requirements on the control plane and software controller performance and is more robust against network failures in the  
Figure 10: Reactive flow management. control plane.