# A Comprehensive Survey on Knowledge-Defined Networking
## 6 Data Plane
### Forwarding Devices
#### 6.2.2 Physical Switches
Assigning a timeout to different flows in the flow table such that, once the timeout is reached, such flows will be automatically removed from the flow table is one way to manage flow table entries [410]. Another approach to managing the flow table is to aggregate flow rules using prefixes or by splitting and distributing flow rules [411]. Furthermore, flow rule caching using a two-tier approach has shown better switch memory utilization [412]. Some have used OpenFlow switches to handle short flows using flow rules, while large flows are handled by contacting the controller, which has resulted in a significant reduction in flow-table entries [310]. Some researchers have attempted to use distribution frameworks to decompose large flow tables into smaller ones and optimally distribute them across the network while preserving the policies [413]. As reviewed in Section 5.2.2, there are numerous proposals for the implementation of switch forwarding models using protocols such as OpenFlow [291], ForCES [292], OpFlex [293], POF [294], PCE-PCC [295], OpenState [296], etc. OpenFlow and ForCES both have a completely logically separated control plane from the data plane, whereas in OpenFlow, the control plane is typically physically separated from the forwarding devices, while in ForCES, the control plane can exist in the same device. In OpFlex, a part of the control plane is redistributed to forwarding devices in order to improve the scalability of KDN, even though the policies are logically centralized. Compared to OpenFlow, in POF, flow instruction sets are used for packet forwarding, where flow table matching using header fields is not necessary, which speeds up forwarding in switches. In OpenState, OpenFlow match-action is extended to finite state machines for doing stateful tasks inside the switches, which can be considered again as an attempt to decentralize some control back to forwarding elements. However, OpenFlow is the most widely used implementation for switches in KDN, as it implements the original SDN concept of complete decoupling of the control plane from forwarding elements. Table 7 summarizes existing protocol details that implement switch forwarding models. Switches can be implemented in general PC hardware, open network hardware, or vendor hardware. In general, in PC hardware implementations, the forwarding device is implemented as software running on the host operating system [414]. A fast data path based on caching of flow table entries in onboard classification hardware on the network interface card to improve lookup performance of PC-based OpenFlow switching in Linux has been presented in [415]. The authors in [416] highlight that the performance of PC-based switches is lower compared to dedicated hardware-based switches due to the fact that packet input-output in the operating system's network stack is a significant bottleneck. This work analyzes several PC-based switch implementations such as Linux IP forwarding, Linux bridge, Open vSwitch, Data Driven Packet Processing (DDPK), and Layer 2 Forwarder (L2 FWD) and shows that the performance of the DDPK is nearly six times that of the Open vSwitch. Open network hardware-based switches are mostly used for testing and development of forwarding devices, which provides a vendor-independentplatform to build switches. NetFPGA is an open network hardware-based platform to build high-performance networking systems in hardware, which uses FPGAs to implement core data processing functions [417]. Using NetFPGA as the platform, SwitchBlade and ServerSwitch are practical examples of the implementation of physical switches using open network hardware [418]. Finally, vendor-specific switches provide several advantages over open network hardware-based switches, such as better integration with products from the same vendor, ease of deployment, support for specialized features from the vendor, etc. However, there are some drawbacks, such as vendor lock-in, reduced interoperability with other vendors, limitations in flexibility and scalability, etc.