HyFI: Hybrid Flow Initiation in Software DefinedNetworks

Ahmad SoltaniInformation Systems Dep., Informatics Institute

Middle East Technical UniversityAnkara, Turkey

ahmad.soltani@metu.edu.tr

Cuneyt F. BazlamaccıElectrical and Electronics Eng. Dept.

Middle East Technical UniversityAnkara, Turkey

cuneytb@metu.edu.tr

Abstract—Software defined networking (SDN) provides tech-niques to facilitate the management of computer networks in acentralized and integrated architecture by separating the controlplane from the data plane in packet forwarding devices andmiddleboxes. By creating this abstraction layer, SDN allowscontrol of network middleboxes remotely from a controller point,which is either connected directly (out-of-band control usingdedicated links) or indirectly (in-band control using the availabledata network links) to the middleboxes. Flow initiation methodsused for unknown flows in out-of-band control mechanism arenot optimized for use in in-band controllers. Therefore, handlingflow initiation and controller discovery for hybrid SDN’s andcases where the control and data traffic flow on the same networkare still challenges yet to be addressed. The present study firstincludes a review of the current state-of-the-art in tackling flowinitiation challenge and then addresses the problem in SDN’swith in-band controllers by proposing a hybrid mechanism thataims to minimize the delay in the transmission of new flowsduring flow initiation. Our proposal uses a unified network mapon the controller to form apriori network information and thenconfigures the switches appropriately. By modeling flow initiationin OpenFlow, the present study also compares the implicationsof the proposal with the flow initiation methods currently usedin out-of-band controllers today.

Keywords—Software Defined Networking, OpenFlow, Flow Ini-tiation Overhead, Hybrid SDN’s, In-Band Controller

I. INTRODUCTION

With today’s new technology requirements, computer net-works and specifically the Internet is expected to providemobile, distributed and constantly changing services to itsusers. But in the past four decades, computer networks didnot go through an evolution in its mechanisms and architecturethat can facilitate this change in requirements. This is mostlybecause forwarding middleboxes and interfaces are configuredto have their low-level switching operations tightly coupled totheir high-level control definitions and algorithms. SoftwareDefined Networking introduces an abstraction layer betweenthose low-level and high-level functionalities by introducinga standard protocol to act as an interface, which dividescontrol and data planes in middleboxes and routers. Thereare a number of challenges related to SDN, most of whichare treated with conventional network or computer sciencetechniques. Some other challenges that are unique to SDNparadigm, such as flow initiation and controller handling, alsoexist.

A computer network, as a communication infrastructure, isan important technical aspect of how one implements and usesa computerized information system, a distributed computingsystem or a communication system. Computer networks wereinitially designed to serve fixed hosts with topology dependentaddresses, which drastically differs from what they are usedfor nowadays [1]. Emergence of SDN as an evolution of con-cepts introduced in mid 2000’s [2] brought an unprecedentedopportunity to diminish this gap but of course introduced newchallenges in return.

OpenFlow, one of the most successful implementations ofSDN, uses a secure protocol that allows implementation ofhigh level control functions in switches by installing rules intotheir flow tables. When a switch receives a packet, it comparesthe packet header fields with the available rules and appliesthe set of mandated actions accordingly. For example, it mayforward the packet to a port, drop the packet or delay it. Incase there are no rules associated with the packet, the switchqueues the packet in its memory and asks the controller for aset of actions for this new packet. The present paper focuseson flow initiation algorithms in OpenFlow to address one ofthe challenges SDN’s with in-band control mechanisms.

By separating control and data planes in computer net-works, SDN provides an abstraction between the forwardingand decision making mechanisms of routers and middleboxesin networks. Thus a central controller is able to dictate policiesand network control rules to forwarding elements in SDN.SDN promises ease of network management from a singlecontrol point, shrinking number of configuration faults andexpenses and increasing independent research and evolutionopportunities for control and data planes. But SDN introducesa number of challenges such as controller discovery, multiplecontroller management, network integrity, configuration veri-fication and scalability.

In the following parts, the flow initiation problem is intro-duced in section II, literature review is presented in section IIIand our hybrid flow initiation approach is given in section IV.Section V includes the results of our simulations and findingsand section VI concludes the paper.

II. PROBLEM DEFINITION

In software defined networking, the process necessary fora switch to obtain its forwarding rule set for a newly arrivingpacket flow is called ’flow initiation’ and the time it takes to978-1-4799-3023-4/14/$31.00 c© 2014 IEEE

install the related forwarding rules is called ’flow initiationoverhead’ [3]. This overhead affects the time it takes for thefirst packet of the flow to reach its destination.

The present study enhances SDN flow initiation processby proposing a hybrid approach that uses currently availablemethods to minimize the time needed for the initiation. Al-though extra controller traffic is introduced by the proposedalgorithm as a consequence and trade-off, approaches such asService Centric Networking (SCN) might bear solutions thatmitigates the side effects of such a trade-off. To tackle SDNbottleneck issues, which is common in all centrally controlledsystems, a variety of solutions have already been proposed [4].

As a result of the following literature review, it can beconcluded that a bottleneck controller will not be a criticalissue in the near future since more specialized hardwareare expected to be introduced. Alternatively, Service CentricNetworking mechanisms, as introduced in for example ServalProject [1], can also resolve such issues. Although flow initi-ation overhead does not pose a big scalability challenge andthreat in the near future, thanks to high capacity controllersthat can handle thousands of requests with low latency [3],enhancing the time needed for the initial packets of a flowto reach their destination during the flow initiation phase alsobrings advantage in optimizing resource usage such as routerbuffer space for example.

III. LITERATURE REVIEW

OpenFlow protocol facilitates experimental network studiesgain pace and also be tested and implemented on real networks.An OpenFlow compliant switch or router still includes lowlevel fast packet forwarding capabilities and local tables buthigh-level routing protocols are implemented on the switchonly by the help of a remote server on the SDN. Unlikeearlier attempts to realize data and control plane separation,such as Ethane [5], OpenFlow does not require customiza-tion of hardware. Furthermore, earlier attempts such as RCP[2] made deployment easier but were limited in what highlevel protocols (BGP, RIP, etc.) could support. Therefore theycould not lead to further innovation or fast introduction ofnew protocols. Another previous attempt ForCES [6], unlikeOpenFlow, required standardization, adoption and deploymentof new hardware.

Quite a variety of controllers have been developed indifferent programming languages (NOX and POX [7], Bea-con [8], Maestro [9], etc.), which adopt OpenFlow standard.Openflow Switch Specification [10] defines that when a switchreceives a packet that does not have a rule and a set of actionsassociated with it in its forwarding table and when the switchhas enough buffer memory, packet in message event takesplace and after buffering the newly arrived packets, packet inmessage which contains sections of the original packet headerand the bufferID, is sent to the controller so that the controllercan set the forwarding rule for this new flow [11]. When thecontroller makes a decision about this newly arriving flow,using OpenFlow with TLS or TCP protocols, it inserts a rule(or set of rules if needed) in the forwarding table of theassociated switch. Afterwards, the switch acts on the bufferedpacket(s) and all consequent similar packets based on thisnewly installed rule. In case a switch does not support packet

buffering or has run out of memory, it forwards the wholepacket stream to the controller instead and acts on the newrule only whenever it is dictated by the controller. Meanwhileother packets that arrive in the same flow may be timed outor automatically dropped on the way until the new rule isinstalled. If buffer size is adequate, initial packets of a flowwait in the buffer until the controller dictates the action setsto the switch as a row in its flow table. However, in casesof buffer overflow or TTL expirations there is a possibility ofunnecessary resource usage in terms of buffer space as wellas unnecessary bandwidth usage in terms of retransmissions.

Proper flow initiation algorithms may decrease the timeand resource expenses that needed for flow initiation whilereducing the time it takes for the initial packets of newflows to reach their destination. There have been a numberof studies conducted to optimize the flow initiation process.Tootoonchian et al. [12] demonstrated that this challenge canbe tackled by modifying the NOX controller hence introducingNOX-MT, which focuses on NOX controller performance andby multithreading and using known techniques such as I/Obatching, etc. This study has introduced a sizable progress incontroller performance. DevoFlow [13], on the other hand,has proposed to handle short-life flows by data plane andpersistent flows by controllers. This method, supported by anASIC, suggests that fewer requests to controller may alleviatethe flow initiation concerns. DIFANE [14], a study on flow-based networking, was introduced in 2010 addressing thesame concern with centralized controller architectures. Yu [14]proposed that proactively installing all possible rules and data-paths and by partitioning these rules among switches and thenforwarding the new packets to the switches that contain relatedrules, dramatically reduces the number of switch-controllerqueries and interactions.

At first glance, we can simply eliminate the buffering stepas an alternative solution and send all new packets to thecontroller and forward those initial packets right from thecontroller point until the optimal path is installed on the sourceswitch. This method will provide the possibility to programthe controller to immediately forward initial packets it receivesduring the flow initiation process and reducing the time it takesfor the first packets to arrive at their destination in certain casesalso reducing the buffer expense. However in certain cases, thismethod will cause unnecessary use of bandwidth and generatehigh traffic on the controller.

IV. HYBRID FLOW INITIATION

As was already stated in section II, flow initiation processmay cause a notable delay in the arrival time of the firstpackets of undefined flows in OpenFlow based SDN’s within-band controller(s). Flow initiation process in current SDN’stakes place as explained in section III and this method willbe referred to as PIT (packet in transmission) method in therest of the present paper. This method is desirable for thosecases in which the destination switch has shorter distance tothe source switch compared to the controller. In other caseswhere the controller is closer to the destination switch, it ismore desirable to forward the initial packets of the flow via thecontroller node rather than making them wait for flow initiationprocess to complete and only then transmitting those initialpackets from the source towards the destination. Figure 1 and

Fig. 1: Desirable case for PIT method.

Fig. 2: Undesirable case for PIT method.

figure 2 demonstrate desirable (green) and undesirable (red)cases for the PIT method. In these and all subsequent figures,links between nodes are assumed to have equal latency. Infigures, light arrows indicate packet in messages, bold arrowsindicate original flows and numbers indicate chronologicalorder of transmissions.

The process in which buffering does not take place in theswitch and the whole flow is forwarded to the controller forboth redirection and decision making purposes, will be referredto as OFT (original flow transmission) method in the rest ofthe paper. This method is more desirable when the destinationswitch has a shorter distance to the controller in comparisonto the source switch. Likewise, it is undesirable to use thisflow initiation method when the source switch is closer tothe destination switch simply because if the initial packetswait in the source switch’s buffer, the time and bandwidthexpense to deliver initial packets to destination will definitelybe less. Figure 3 and figure 4 demonstrate desirable (green)and undesirable (red) cases for the OFT method similarly.

Since both methods have desirable and undesirable cases,we propose a hybrid flow initiation method that resorts to eitherPIT or OFT methods in an optimal way. If all switches obtainrelated apriori information about network topology, then eachswitch may be configured to utilize the most appropriate flowinitiation method for each individual case of unknown flowarrival. This information however is available on the network

Fig. 3: Desirable case for OFT method

Fig. 4: Undesirable case for OFT method.

controllers of an SDN through statistics that a controllerobtains from switches. Hence the authors suggest the followingflow initiation process:

Algorithm: An initiation process should be available onthe controller, which installs proactive rules on all switcheson the network based on the results of an analysis that takesplace before actual flow initiation events occur. By populatingan adjacency matrix of nodes in the network, this processobtains information about all possible source-destination pairsin the network and then decides if a particular destination hasa shorter distance to the controller or to the source switch ina potential flow. Based on this, the controller then asks theswitches to perform either the PIT or the OFT method as theirflow initiation process. The proposed mechanism involves aswitch, either local on the controller machine (the controlleroperating system is installed on a switch), or connected viadedicated, highly reliable and fast link, and uses the availableunified network map as apriori knowledge in order to analyzethe whole network to pre-configure the above task. Thus itcauses the switch to have its flow initiation method based onthe relative locations of source and destination with respect tothe controller in network. In a network with n nodes (includingthe controller) every switch will have maximum of n − 1proactive rules (for flows destined to other switches and thecontroller) installed at the lowest priority row of their flowtable. We, in this way, ensure that further network policy rulescan be installed on top of these proactive rules to override

Fig. 5: Both cases are desirable for Hybrid method.

proactive rules if necessary. This process can be repeated bythe controller in a timely manner or based on specific loadanalysis events on the network. It is worth noting that this studydoes not aim to minimize the number of flow initiation queriesin a network, but instead aims to contribute by reducing thetime required for the first packets of new flows to reach theirdestination. This will also mitigate the risks of buffer over-flows in switches that result in initial packets being droppedand retransmitted.

It is also possible to prove mathematically that the Hybridmethod presented above results in a shorter arrival time for theinitial packets of new flows. On a single network,

Epit = Es + Ef and Eoft = Es′ + Ef ′ (1)

andEhyb = Es′ + Es (2)

where the average of initial packet arrival times are representedas:Epit for cases where packet in transmission method is usedEoft for cases where original flow transmission method is usedEhyb for cases where Hybrid method is usedEs for desirable cases in packet in transmission methodEs′ for desirable cases in original flow transmission methodEf for undesirable cases in packet in transmission methodEf ′ for undesirable cases in original flow method

For the proposed Hybrid flow initiation method to bepreferable, the following should be satisfied:

Ehyb ≤ Epit and Ehyb ≤ Eoft (3)

which can only hold if

Es′ ≤ Ef and Es ≤ Ef ′ (4)

Equation 4 in fact is satisfied, since in desirable cases byemploying the OFT method, initial packets are transmitted tothe controller during the flow initiation process while it isknown that the controller is closer to the destination comparedto the source, where (on the same network) in undesirablecases by employing the PIT method, initial packets are requiredto wait on the source switch buffer until the initiation processis over and then be transmitted to the destination switch.

On the other hand, in desirable cases for the networkemploying PIT method, initial packets wait in the source

Fig. 6: Experiment 1: Linear topology.

Fig. 7: Experiment 1: Initial packet arrival time comparison.

switch buffer and are transmitted to the destination as soonas flow initiation phase is over while it is known that thesource has a faster path to the destination compared to thecontroller, where (on the same network) in undesirable casesby employing OFT method, initial packets are transmitted tothe destination switch from the controller which has a sloweraccess path to the destination.

V. SIMULATION RESULTS

In order to simulate and test the proposed hybrid method, asimulation environment, in which in-band control mechanismsand currently implemented flow initiation methods in Open-Flow, can be modelled and be compared to each other, has beenimplemented. To test the latency of the initial packets of flowsin different cases of packet in transmission (PIT), originalflow transmission (OFT) and Hybrid method (HYB), first anexperiment using a linear topology is conducted as experiment1. In this experiment host h1 forwards an echo packet to hosth2 and consequently host h2 replies with an echo reply packet.Since we simply used uniformly distributed random delays onthe links for simulating the background traffic, experiment 1 isrepeated 4 times for all three methods and the delay betweenthe time h1 sends its echo message and the time it receivesthe reply is recorded and compared.

Experiment 1 is repeated for a non-linear topology also asexperiment 2 as shown in figures 8 and 9.

Fig. 8: Experiment 2: Non-Linear topology.

Fig. 9: Experiment 2: Initial packet arrival time comparisonfor 1Mbps and 100Mbps links

In experiment 3, an arbitrary topology is employed. First,all hosts in the network start sending random numbers of echopackets with random time delays to random destinations andthe average number of ’send’ and ’receive’ events are plottedto observe the time delay between packet send and receiveevents for all of the three flow initiation methods. Figure 11is a detailed view on the interfaces of the third experiment infigure 10:

Fig. 10: Experiment 3: Arbitrary topology.

Fig. 11: Experiment 3: Arbitrary topology detailed view

Fig. 12: Experiment 3: Number of packets in switch bufferduring flow initiation with PIT method

Number of packets in the switch buffer during flow initia-tion with PIT and Hybrid methods are depicted in figures 12and 13, respectively.

Number of echo and echo reply packets ’send’ and ’receive’events are plotted for all of the three flow initiation methods.Results of PIT, OFT and finally Hybrid methods are shown infigures 14, 15 and 16, respectively.

As seen in experiment 1 and 2, the Hybrid methoddemonstrates lower latencies when compared to other flowinitiation methods in both linear and non-linear topologies.In experiment 3 the same conclusion can be derived that theHybrid method yields equal or better results when it comesto initial packet delivery latency. This conclusion can alsobe derived when the difference in the number of ’send’ and’receive’ events in figures 14, 15 and 16 are evaluated atspecific time instances and intervals during the simulation.

When packet population in the buffer of switches areevaluated in figure 12 and 13, it is observed that not only

Fig. 13: Experiment 3: Number of packets in switch bufferduring flow initiation with Hybrid method

Fig. 14: Experiment 3: Number of packet ’send’ and ’receive’events with PIT method

Fig. 15: Experiment 3: Number of packet ’send’ and ’receive’events with OFT method

the maximum number of packets in the buffer is lower, butalso less number of switches buffer packets for flow initiationprocess when Hybrid method is utilized.

VI. CONCLUSION

In this paper, a hybrid method is presented to tackle one ofthe challenges that is unique to SDN architecture to reduce thetime needed for initial packets of new flows to arrive at theirdestination switch. The proposed solution takes advantage ofthe previously implemented approaches and uses the internalnetwork topology available at the controllers to decide when toutilize advantageous cases to shorten the time needed for initialpackets of new flows to be transmitted to their destination.

The solution provided in this study might in turn face abottleneck issue at the controller. Replicating the controllerinstances may eliminate this bottleneck. It is worth noting thatas a result of replicating the controller service instances, han-dling multiple controllers (service discovery, load balancing,failover, etc.) springs up as a new challenge. But it is possibleto argue that using a service centric approach to resolvemultiple controller challenges is as applicable as for any otherdistributed service over the network. In case controller serviceis considered, this is no different than any other service type.SCNs, and particularly Serval, claim a fundamental progress inaddressing the issues related to multiple and dynamic serviceinstances such as service discovery, load balancing and failoverscenarios and hence we believe that our proposed hybridapproach is feasible to be implemented.

It may also be argued that the presented study wouldrequire a switch to act as a controller, in other words it mayrequire a controller to have switching capabilities to forwardpackets and flow modification messages. We do not consider

Fig. 16: Experiment 3: Number of packet ’send’ and ’receive’events with Hybrid method

optimally addressing this issue in the present study but wesuggest that using a highly reliable and fast link between aswitch and a controller (where the controller is connected toonly one local switch) or alternatively implementing the SDNcontroller on a switch instead of an arbitrary work stationwould provide the environment necessary for the implementa-tion of the Hybrid method proposed.

REFERENCES

[1] E. Nordstrom, D. Shue, P. Gopalan, R. Kiefer, M. Arye, S. Y. Ko,J. Rexford, and M. J. Freedman, “Serval: an end-host stack for service-centric networking,” in NSDI’12: Proceedings of the 9th USENIX con-ference on Networked Systems Design and Implementation. USENIXAssociation, Apr. 2012.

[2] N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh, and J. van derMerwe, “The case for separating routing from routers,” in FDNA ’04:Proceedings of the ACM SIGCOMM workshop on Future directions innetwork architecture. ACM Request Permissions, Aug. 2004.

[3] S. H. Yeganeh, A. Tootoonchian, and Y. Ganjali, “On scalabilityof software-defined networking,” Communications Magazine, IEEE,vol. 51, no. 2, pp. 136–141, 2013.

[4] The Open Networking Foundation, “OpenFlow Switch Specificationv1.2.0,” The Open Networking Foundation, Dec. 2011.

[5] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, andS. Shenker, “Ethane: Taking control of the enterprise,” SIGCOMM, pp.1–12, 2007.

[6] L. Yang, R. Dantu, T. Anderson, and R. Gopal, “Forwarding and ControlElement Separation (ForCES) Framework,” Network Working Group,Apr. 2004.

[7] NoxRepo. NOXRepo. [Online]. Available: http://www.noxrepo.org[8] D. Erickson. What is Beacon. [Online]. Available:

http://openflow.stanford.edu/display/beacon/home[9] T. S. Eugene Ng, A. L. Cox, Z. Cai, F. Dinu, and J. Zheng. Maestro-

Platform. [Online]. Available: http://code.google.com/p/maestro-platform/

[10] The Open Networking Foundation, “OpenFlow Switch Specificationv1.1.0,” The Open Networking Foundation, Feb. 2011.

[11] “OpenFlow Switch Specification v1.3.0,” The Open Networking Foun-dation, Jun. 2012.

[12] A. Tootoonchian, E. Nordstrom, S. Gorbunov, D. Shue, Y. Ganjali,P. Gopalan, R. Kiefer, M. Arye, S. Y. Ko, J. Rexford, and M. J.Freedman, “On controller performance in software-defined networks,”Enterprise Networks, 2012.

[13] A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma,and S. Banerjee, “DevoFlow: Scaling flow management for high-performance networks,” SIGCOMM, pp. 254–265, 2011.

[14] M. Yu, U. Alon, R. D. McKinney, J. Rexford, R. D. McKinney,M. J. Freedman, W. A. Montgomery, J. Wang, W. A. Montgomery,H. Ouibrahim, H. Ouibrahim, P. Sijben, P. Sijben, J. J. Stanaway, Jr., andJ. J. Stanaway, Jr., “Scalable flow-based networking with DIFANE,” inSIGCOMM ’10: Proceedings of the ACM SIGCOMM 2010 conference.ACM Request Permissions, Aug. 2010.