 network topology requires high accuracy at any given time, thus we should use strong consistency to it. But the network mea- surement data may not be as critical and can tolerate delay, SO a weak consistency may suffice. For strong consistency, we can use traditional DB transactions. For weak consistency, we can use distributed hash table (DHT). 4.2 SDN Controller 4.2.2 Apps on SDN Controller The SDN architecture consists of application, control, and infrastruc- ture layers. The interface between the application and control layers is how applications inform the network of their policy requirements. Examples of policy requirements are as follows: a security application may need all of an infected hosts a traffic redirected to a remedia- tion server; a QoS application may need voice traffic delivered within a specified latency; and a troubleshooting application may need a copy of specific communication sent to a network administrator's protocol analyzer. Implementing their policies by writing low-level, prioritized flow table rules through a controller pass-through interface into the switches in the network has several problems. Correctness: When multiple SDN applications operate on the same network, the flow table rules written by these applications can con- flict and cause the network and applications to fail to operate cor- rectly. Since OpenFlow rules are prioritized, and only the first to match is executed, only one of the applications, the one that used the higher priority, will have their rules correctly enforced. Coupling: When an SDN application directly writes flow table rules, it must first comprehend the network design and infras- tructure capabilities. In addition, an SDN controller may be using a mix of traditional protocols in a hybrid SDN network, along with OpenFlow. In this commonly occurring case, the application must understand the network design and technologies in use to successfully program rules into the network. If the controller is updated, or reconfigured, it may change the network desig