# A Comprehensive Survey on Knowledge-Defined Networking
## 6 Data Plane
### Forwarding Devices  
#### 6.2.1 Architecture of a Forwarding Device  
The architecture of a KDN forwarding device, along with flows between management and control planes [399], is given in Figure 9.  
The forwarding devices can be physical/virtual switches, routers, wireless access points, etc. These devices are configured and monitored by the management plane, while flow rules are installed by the controller, as evident from Figure 9. Note that, compared to an SDN switch, a KDN switch has data to be sent to the management and control planes. Note that, as evident from Figure 9, device topology data and traffic flow statistics data are jointly collected by the management and control planes (using OpenFlow), while data such as resource utilization, event logs, sensor data, etc. are collected by the management plane (using SNMP/OF-CONFIG + DCM), while data such as QoS data, security events, routing protocols, etc. are exclusively collected by the controller (using a DCM). Forwarding devices do not have the intelligence for control in order to take autonomous decisions, as all rules are explicitly defined by a logically centralized controller. As discussed previously in Sections 4 and 5, and as evident from Figure 9, protocols such as SNMP/OF-CONFIG can be directly used for device configuration and to collect configuration data, while protocols such as OpenFlow can be used for flow rule installation.  
Figure 9 depicts a pure KDN switch with data flows, where only KDN-based forwarding using flow tables takes place. However, the pure KDN switch architecture is difficult to integrate with legacy networks. In Section 5.3.1, we presented the high-level architecture of a hybrid KDN switch. Note that, in the presented hybrid switch, the KDN module refers to the pure KDN switch presented in detail in Figure 9. Note that the local control agent is not implemented in a pure KDN switch, while the control channel is directly connected to the KDN module in that switch.  
Figure 9: KDN forwarding device architecture in data plane with different flows exchanged with other planes.  
As shown in Figure 9, an OpenFlow flow table basically consists of three fields called rules, instructions, and statistics. Rules contain the switch port, source MAC address, destination MAC address, source IP address, destination IP address, source TCP address, destination TCP address, Virtual Local Area Network (VLAN) ID, etc. to match against incoming packets. Once matched, one of four actions--forward to port, forward to controller, modify header fields, or drop packet--will be taken. If there is a mismatch, the corresponding action for the incompatible (unmatched) flow table entry will be carried out. The action for a mismatch can be one of dropping the packet, searching in the next flow table, or forwarding to the controller. In order to request the controller in case of a missing flow table entry, the forwarding device should send a \"packet-in\" message to the controller, where the controller will compute the paths and send a \"Flow-mod\" packet back to the switch to modify the flow table with forwarding information for the packet. Furthermore, the controller can collect flow statistics exclusively maintained by the flow table in the statistics field using \"Switch Feature\" messages and event-based messages such as port changes using \"CPort-status\" messages.