 [84]. It com- prises a programming framework for SDN Apps and a configurable coordinator that detects and mediates these conflicts on behalf of the SDN controller. 4.3 SDN Data Plane OpenFlow was initially proposed to decouple the routing intelligence (software) from simple forwarding (hardware) allowing, particularly for academic research networks and test beds, fast prototyping and evaluation of new control methods and algorithms. OpenFlow provides an open control interface to the operating system of the network device without compromising the details of the implementation. This guarantees the business benefits for equipment manufacturers SO that it will be more likely to be adopted by the industry. OpenFlow needs the support from the operating system. It is based on the ternary content addressable memory (TCAM)-based flow tables. In a classical router or switch, the fast packet-forwarding 4.3 SDN Data Plane (data path) and the high-level routing decisions (control path) colocate on the same device. An OpenFlow-enabled switch separates these two functions. The data path portion still resides in the switch, but high-level routing decisions are moved to a flow controller, typically a standard server. The OpenFlow switch and controller communicate via the OpenFlow protocol, which defines operation and management (OAM) messages. Figure 4.7 shows the basic component in the initial OpenFlow design. Later OpenFlow has evolved to other more complex struc- tures such as multiple tables. The match field can match any packet headers, for example, Ethernet address, IP headers, or MPLS header fields. The typical actions can be forward, modify, and drop. Each entry is associated with a counter for collecting statistics purposes. Similar to routing or access control rules, each rule has a priority. When multiple rules match the same packet, the one with higher priority is selected. Finally, each rule has an expiration time. This is for preventing outdated rules. Once the time out is reached, the rule is removed by the switch