Aiding OpenFlow Controller by Enhancing OpenFlow's Control Model, and Behaviour of Flows Othman Othman M.M. , Koji Okamura Kyushu University Proceedings of the TNC2013 Conference 6 June 2013, Maastricht, Netherlands

Outline: Motivation and Goal. An attempt to solve the problem (3 enhancements). First: Network Equipment to Equipment flow installation. Second: Proactive Flows. Evaluation. Conclusion.

1-Motivation and Goal. Controller might be bottleneck. Tight coupling between OpenFlow switch and controller. Every thing is up to the controller. [1] “When using OpenFlow in high speed networks with 10 Gbps links, today’s controller implementations are not able to handle the huge number of new flows.” Equipment can also be a bottleneck. Limited resources Flow Table size. Processing etc. Michael Jarschel, Simon Oechsner, Daniel Schlosser, Rastin Pries, Sebastian Goll, and Phuoc Tran-Gia. 2011. “Modeling and performance evaluation of an OpenFlow architecture”. In Proceedings of the 23rd International Teletraffic Congress (ITC’11). ITCP 1-7. 3

1-Motivation and Goal. Considering Future Internet with many applications supported by OpenFlow. Specific routing, Video streaming, Security, QoS. etc. Controller will have many tasks. Figure 1: Security policy maker/manager Application/service provider. 4

1-Motivation and Goal. Improve OpenFlow. Support self-reactive behavior. Reduce load on controller. Step towards having wider adoption of OpenFlow. If OpenFlow is thought of as one of the Future Internet technologies, However some debate that OpenFlow have some limitations. So our aim is to aid OpenFlow, to make it more suitable for wider adoption and implementation within networks or in whole OpenFlow networks.

2-An attempt to solve the problem. Network equipment to Network equipment Flow Programming: To create self-reactive network. Can be used to delegate some flows to less loaded network equipment. To easily program whole network without loading controller. New type of Flows (Proactive Flows): To provide the controller with a more relaxed way to handle precisely timed tasks. Programed as inactive flows and later activated by the flow. Can cooperate with Device to Device programming.

2-1- Network Equipment to Equipment flow installation. Figure 1: OpenFlow Control Mode Current OpenFlow’s control model: Controller to Equipment only: Equipment exchange information only with the controller. Current Internet: Equipment to Equipment only: equipment exchange information with each other. Target: Controller to Equipment, AND Equipment to Equipment: to give OpenFlow the ability to exchange information between equipment in addition to controller. Fig2. Regular Network Information exchange. Figure 3: Enhanced OpenFlow Control Mode

2-1- Network Equipment to Equipment flow installation. To reduce load off the controller. Give the equipment ability to act by their own to reduce load off loaded equipment. PE P Packet Flows to manipulate headers in packets Fig1. Equipment overloaded, due to many flows to carry out. PE P Fig2. Overloaded equipment delegates some flows to other equipment. PE P Packet Flows to manipulate headers in packets Fig3. Reduced load off the overloaded equipment.

2-1- Network Equipment to Equipment flow installation. Alternative way to install flows to whole network (e-e propagation). To reduce load off the controller. Controller Fig1. Regular way of installing flows. Controller installs to equipment one by one. Controller Fig2. Network equipment install flows to each other.

2-2- Proactive Flows. ? Original OpenFlow: flows activated by default, controller keeps track of time and install flows on time. Migration Fig1. Migration and Redirection using OpenFlow. Migration ? Fig2. Delay due to controller overload in Migration.

2-2- Proactive Flows. Proactive Flows: Initially installed as inactive. (not usable). Activated on right time, by: Explicit activation packet. Activation Flow. Preset time. Controller can install the flow ahead of time. Migration Fig1. Migration and Redirection using OpenFlow and Inactive Flows. Proactive Flows Flows activation

3- Evaluation: Run simulation on OMNet++ using : Regular OpenFlow. Modified OpenFlow.

3-Evaluation: 1-Ne-Ne FI for distributing flows on behalf of the controller. Scenario. Shown in figure 1. To measure: Totoal_NeNeFI_install_time: the total time needed for the flows to be installed on the whole set of required equipment. (1) T(e) represents the time at which the flow installation reaches equipment e where eϵE , and T(0) is the time at which the controller imitated the Ne-Ne FI method. Figure 1. (a) Regular flow installation. (b) The flow installation using Ne-Ne FI.

3-Evaluation: 1-Ne-Ne FI for distributing flows on behalf of the controller. Scenario. Shown in figure 1. To measure: Totoal_number_of_NeNeFI_messages: total number of packets exchanged in order to enable the Ne-Ne FI installation on behalf of the controller. MNe-Ne FI(e) is the number of all messages belonging to the Ne-Ne FI sent by equipment e where eϵE. Figure 1. (a) Regular flow installation. (b) The flow installation using Ne-Ne FI.

3-Evaluation: 1-Ne-Ne FI for distributing flows on behalf of the controller. Scenario. Shown in figure 1. To measure: Totoal_size_of_NeNeFI_messages : total size of packets exchanged in order to enable the Ne-Ne FI installation on behalf of the controller. SNe-Ne FI (e) is the size of all messages belonging to the Ne-Ne FI sent by equipment e, where eϵE. Figure 1. (a) Regular flow installation. (b) The flow installation using Ne-Ne FI.

3-Evaluation: 1-Ne-Ne FI for distributing flows on behalf of the controller. Scenario. Shown in figure 1. Compare all to regular case. Figure 1. (a) Regular flow installation. (b) The flow installation using Ne-Ne FI.

3-Evaluation: 2-Delegating Flows off the Overloaded Equipment using Ne-Ne FI Scenario: The concept of overloading: Can be TCAM memory is running out. Or other resources. To Measure: Ratio_of_overloading_pe: the ratio of load of the edge equipment over the average load of the other network equipment. Lavg(e) represents the average load of equipment e , where eϵN. Figure 1. (a) Equipment overloaded, due to many flows to carry out. (b) overloaded equipment delegates some flows to other equipment. (c) Reduced load off the overloaded equipment.

3-Evaluation: 2-Delegating Flows off the Overloaded Equipment using Ne-Ne FI Scenario: The concept of overloading Can be TCAM memory is running out. Or other resources. To Measure: Time_to_reduce_pe_load: the time needed to reduce load off the overloaded equipment. Te(load value) represents the instance of time at which equipment e, where eϵN, has reached the specified load value. Figure 1. (a) Equipment overloaded, due to many flows to carry out. (b) overloaded equipment delegates some flows to other equipment. (c) Reduced load off the overloaded equipment.

3-Evaluation: 3- Proactive Flows. Scenario: Figure 1. (a) Migration and Redirection using regular OpenFlow. (b) Migration and Redirection using OpenFlow and Proactive Flows.

3-Evaluation: 3- Proactive Flows. Figure 1. (a) Migration and Redirection using regular OpenFlow. (b) Migration and Redirection using OpenFlow and Proactive Flows. Scenario: To Measure: Tredir which represents the time at which the controller installs the redirection flows, and compare it with that Treq, which is the time at which the first request will arrive to the server after it completes the migration.

3-Evaluation: 3- Proactive Flows. Figure 1. (a) Migration and Redirection using regular OpenFlow. (b) Migration and Redirection using OpenFlow and Proactive Flows. Scenario: To Measure: Treq, and Tproactive while also counting the number of unanswered request. And finally we will compare the number of unanswered requests in the cases of regular OpenFlow and the proactive flows.

4- Conclusion: Aim to aid OpenFlow by reducing load off the controller, make OpenFlow’s equipment self-aware and self-reactive. Achieving goals by proposing a new enhancements to OpenFlow: Network equipment to equipment Flow Installation. Proactive Flows.

Q&A: Thanks for listening