Priority based Flow Rule Request Message Processing Mechanism in the OpenFlow Switch

In the SDN, the controller is in charge of the maintenance and administration of variable aspects like the network topology and the network resources etc. of the whole network. Administrative strategies are made upon these work and sent to the switches from the controller so as to instruct the network devices to apply appropriate policies to the data flows. As for the data packet which reaches the ingress OpenFlow switch for the first time, the packet itself or a fraction of the packet will be encapsulated into a packet-in message and will be sent to the controller to request for a new flow rule. After the flow- mod message and the packet-out message are sent back to the switch from the controller, the determined forwarding action will be applied to the certain data flow. So far, the inbound latency caused by the creation of the packet-in message and the outbound latency caused by the receive and the execution of the flow-mod message are highlighted when it comes to the concerns about the latency and the effectiveness of the data transportation in the SDN[Mazu]. Attention to the studies on the processing order of the flow rule request message like the packet-in message and the packet-out message is comparatively low. As the SDN continually grows in scale and complexity and the packets' forwarding policies become more recursive and dynamic, the number of the switches under the administration of the same controller is elevated and unavoidably causes the network congestion problem widespread. The scale of modern networks and data-centers and the associated operational expense deteriorates the delay problem in the network with congestion. The ability to help the services with high priority be processed without delay becomes critical. This document proposes the combination of appending a priority tag to the packet-in message and the Priority based Flow Rule Request Message Processing Mechanism(PFRRMPM) as a solution to help the data flow with high priority or lantency-sensitive to acquire the forwarding rule without or with shorter waiting latency when there are excess flow rule request messages in the SDN.